Cloud computing changed the required skills for software engineers and system administrators. IT departments that didn’t continuously researched and adopted new technologies are usually caught off-guard when they decide to “move to the cloud”. 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’ll be speaking in this article. Internally, we call this role the cloud native engineer*.
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.
The list of relevant technologies in the cloud native context is overwhelming:
But don’t worry, you don’t need to know them all. You’ can’t either have “3+ years of production experience” as some naive recruiters would expect, because it’s a very new field. By the way, there’s another map for serverless.
So let’s go one by one over the required building blocks of every cloud project, the bread and butter of the cloud native engineer skillset**.
Software Architecture (from monoliths to microservices and serverless)
You’ll need to figure out if you’re dealing with a micro-service architecture or with a monolith. If you’re not assigned to a greenfield project, most of the time you’ll 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
To understand what microservices are all about, read Martin Fowler’s article on the subject. Sam Newman’s book is the “bible” in this domain.
Building the software (development and build scripts)
Once you know with what type of architecture you’re dealing, you’ll 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.
Packaging (containers: Docker | Serverless)
In the cloud native context, applications get delivered as containers (serverless is gaining traction as well). So you’ll need to be able to understand and package applications into these new standards. My colleague’s (Adrian Mouat) Using Docker book is probably your best option for getting up to speed.
Continuous integration/delivery (CI/CD tools like Jenkins, GitLab, Travis and friends)
Once the code (both applications and infrastructure) is written, you will need to deploy it somewhere. Most of the “old” continuous integration tools are still alive and kicking and they’ve 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.
Container Schedulers and Orchestrators (Kubernetes, Docker Swarm, DC/OS)
If you package your application in containers you’ll need to understand their lifecycle. Kubernetes is becoming the standard in this space, with managed solutions from all major cloud providers. Go over the basic tutorials 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.
Building the infrastructure (the operations part)
OK, you have some application code that works. Your next step (for greenfield projects it’s 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, Cloud Formation, Ansible are the usual suspects in this area.
Monitoring and observability
Monitoring plays a central role in a distributed system. The old tools didn’t manage to catch up with the new landscape, so you’ll need to look into SaaS solutions, the default services offered by your cloud, or rely on open source projects (like Prometheus/Grafana).
Cloud computing building blocks
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.
Once your IT department implements those block, there are other areas that usually gain attention:
- Deployment patterns for your application
- Canary deployments
- Networking for microservice architecture
- Service mesh (istio, envoy)
- Security for cloud architecture
- container vulnerability scans
- Secrets management
The shift to cloud computing reflects as well in the technical skills required to develop and operate the applications on this new platforms. Continuous learning is the only way you can keep up. If you can’t do it at your current workplace, probably it’s time to look for a new challenge somewhere else.
*The skillset and responsibility of this role are different than the Google’s Site Reliability Engineer role: “SRE is what happens when you ask a software engineer to design an operations team” – Benjamin Treynor Sloss – SRE Founder. The DevOps Engineer is a weird name/role that is too vague and always in flux to make comparisons, but it does overlap on some of the skills.
**While shorter than the cloud native landscape, this list is overwhelming as well. I initially assembled it for a colleague (hi Riccardo!) but it is useful for everybody who wants to make a career step in this direction. Most of the people will know the basics and have deep knowledge in a few areas that interest them most.
Looking for a new challenge? We’re hiring!