{"id":219,"date":"2018-10-16T03:46:53","date_gmt":"2018-10-16T03:46:53","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/16\/the-cloud-native-engineer-role\/"},"modified":"2018-10-16T03:46:53","modified_gmt":"2018-10-16T03:46:53","slug":"the-cloud-native-engineer-role","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/16\/the-cloud-native-engineer-role\/","title":{"rendered":"The Cloud Native Engineer Role"},"content":{"rendered":"

Aug 17, 2018<\/p>\n

\n by Catalin Jora<\/a> <\/p>\n

Cloud computing changed the required skills for software engineers and system administrators. IT departments that didn\u2019t continuously researched and adopted new technologies are usually caught off-guard when they decide to \u201cmove to the cloud\u201d. A cloud native IT department requires new skills as the software they have will need refactoring and repackaging to run and take advantage of the new environment, the cloud. About those skills and responsibilities I\u2019ll be speaking in this article. Internally, we call this role the cloud native engineer*.<\/p>\n

A cloud native engineer needs to take an application from a repository through a continuous integration and delivery pipeline. During this journey, she would make sure that the code builds, passes the tests, gets deployed safely and secure up to the to the production environment.<\/h4>\n

The list<\/a> of relevant technologies in the cloud native context is overwhelming:<\/p>\n

\"\"<\/a><\/p>\n

But don\u2019t worry, you don\u2019t need to know them all. You\u2019 can\u2019t either have \u201c3+ years of production experience\u201d as some naive recruiters would expect, because it\u2019s a very new field. By the way, there\u2019s another map for serverless<\/a>.<\/p>\n

So let\u2019s go one by one over the required building blocks of every cloud project, the bread and butter of the cloud native engineer skillset**.<\/p>\n

Software Architecture (from monoliths to microservices and serverless)<\/h4>\n

You\u2019ll need to figure out if you\u2019re dealing with a micro-service architecture or with a monolith. If you\u2019re not assigned to a greenfield project, most of the time you\u2019ll have to move a project from a monolith to microservices. Missing the knowledge about microservices? Check a microservice-demo app here: https:\/\/microservices-demo.github.io<\/a>
\nTo understand what microservices are all about, read Martin Fawler<\/a>\u2019s article<\/a> on the subject. Sam Newman<\/a>\u2019s book<\/a> is the \u201cbible\u201d in this domain.<\/p>\n

Building the software (development and build scripts)<\/h4>\n

Once you know with what type of architecture you\u2019re dealing, you\u2019ll need some basic understanding on how to run and build that project. If you need to adjust\/debug the application, experience or familiarity with the programming language is required.<\/p>\n

Packaging (containers: Docker | Serverless)<\/h4>\n

In the cloud native context, applications get delivered as containers (serverless is gaining traction as well). So you\u2019ll need to be able to understand and package applications into these new standards. My colleague\u2019s (Adrian Mouat<\/a>) Using Docker book<\/a> is probably your best option for getting up to speed.<\/p>\n

Continuous integration\/delivery (CI\/CD tools like Jenkins, GitLab, Travis and friends)<\/h4>\n

Once the code (both applications and infrastructure) is written, you will need to deploy it somewhere. Most of the \u201cold\u201d continuous integration tools are still alive and kicking and they\u2019ve learned how to do continuous delivery. New tools are emerging, but it looks like Jenkins is still the standard, mainly due to poor alternatives. The CI tool will drive the entire delivery process, so designing a good pipeline will result in a better developer experience and faster response to failures\/bugs. All types of tests and code quality tools will have to get integrated here as well.<\/p>\n

Container Schedulers and Orchestrators (Kubernetes, Docker Swarm, DC\/OS)<\/h4>\n

If you package your application in containers you\u2019ll need to understand their lifecycle. Kubernetes<\/a> is becoming the standard in this space, with managed solutions from all major cloud providers. Go over the basic tutorials<\/a> or look for a training if you intend to go deeper into the subject, as this will be your new playground once the apps will get deployed.<\/p>\n

Building the infrastructure (the operations part)<\/h4>\n

OK, you have some application code that works. Your next step (for greenfield projects it\u2019s the first step) is to build the infrastructure where that code will run. This involves a mix of managed services and writing code for the missing parts. Tools like Terraform<\/a>, Cloud Formation<\/a>, Ansible<\/a> are the usual suspects in this area.<\/p>\n

Monitoring and observability<\/h4>\n

Monitoring plays a central role in a distributed system. The old tools didn\u2019t manage to catch up with the new landscape, so you\u2019ll need to look into SaaS solutions, the default services offered by your cloud, or rely on open source projects (like Prometheus<\/a>\/Grafana<\/a>).<\/p>\n

Cloud computing building blocks<\/h4>\n

For most companies, the infrastructure will get replaced by an API, some credentials and a bill that will track the usage. Understanding of cloud computing primitives like compute units, databases, storage, network for whatever cloud\/infrastructure provider you are using is mandatory. Understanding pricing for the new services will help you avoid nasty surprises at the end of the month.<\/p>\n

Once your IT department implements those block, there are other areas that usually gain attention:<\/p>\n