Knowing just the basics of Software Engineering isn’t enough to thrive in today’s market. Many Software Engineers need to have drastically more knowledge of cloud platforms than they currently do.
Why? That’s today’s question. We’re going to be discussing what a Cloud Native Software Engineer is, why they exist, what their skills are and ultimately what that means for you as a Software Engineer.
By the end of this article you should know exactly what a Cloud Native Software Engineer is and why that matters for your career in Software Engineering.
What is a Cloud Native Software Engineer?
Let's start with a definition.
But I’m not simply going to throw a definition at you and leave you hanging, because together we're going to explore and break down the details.
A Cloud Native Software Engineer has typical Software Engineering skills such as writing code, testing, design, architecture, etc. But they differ in that they (critically) have specific skills and knowledge to build applications to leverage cloud platform services for maximal impact.
And when we talk about Cloud here, we mean companies that take another companies code, and run it on their own servers on-demand.
Sounds interesting, but what do we mean about Cloud Native exactly? What makes an engineer a Cloud Native engineer as opposed to just a cloud engineer?
Where does the Cloud Native concept originate?
To start to understand the importance of Cloud Native as a whole we need to understand where the term comes from. Cloud Native as a term relates to a companies aggressiveness when it comes to adopting cloud platform technologies. The more aggressive they are, the more Cloud Native they are. Cloud Native companies will adopt new cloud technologies at a substantial pace and they do so despite the costs.
But what costs am I talking about? Costs such as vendor lock-in, where a company becomes quite heavily reliant on a cloud provider.
Since some companies are so afraid of the costs and risks associated with vendor lock-in we also have a different school of thought: Cloud agnostic companies. Cloud agnostic companies still run workloads the cloud, but they differ as they do everything they can to loosen the ties with a cloud provider. Using software like Containers or abstraction platforms like Kubernetes can help with achieving agnosticism.
But, as with a Cloud Native stance, there are costs. Costs like opportunity costs of forgoing some capabilities that cloud native companies are able to harness. Or the additional cost in developing and maintaining an abstraction layer between your services and the underlying cloud platform.
Now that we know both of these strategies, the natural next question is: Which is best?
Cloud Native or Cloud Agnostic: Which is best?
To answer the question, we need to scrutineer the cost/benefits of each stance. By being Cloud Native, a company can use cutting edge tools, such as Serverless and their companion services like Step Functions, Integrated logging, easier backups... the list is endless, really.
Ultimately the cloud providers give Cloud Engineers the most seamless experience they can. It’s their job to make Software Engineering as easy as possible. AWS is famous for their adage that they remove the “undiffentiated heavy lifting” in software engineering.
But, when a company buys in to the idea of operating in the Cloud it of course comes with a cost... If you heavily use a companies cloud services you are immediately susceptible to the tight coupling you have made. This creates questions like:
- Will the cloud provider support their services well enough?
- Will their SLA’s (basically: uptime) meet our SLAs?
- How much time will we get if they choose to deprecate a service?
- Will changes to their cost structure affect our business adversely?
- What if we want to move cloud providers in future?
- What if they go out of business!?
These are only some of the questions companies ask themselves when deciding on their stance about whether to be Cloud Native or not. And really it comes down to a companies appetite for risk. If a company can be more risky in their approach, they can gain many of the benefits of a Cloud Native approach.
So the answer to which strategy is better is: It depends.
A company should address the risks of going Cloud Native, but also the costs they might incur jumping through hoops to keep their solutions Cloud Agnostic.
You will also find that many detractors who say that Cloud Agnosticism is a fallacy. Because the cost you lose in making services cloud neutral far outweighs the cost of migrating out of a single cloud provider. But the jury is still out on the question and ultimately it comes down to a companies unique position.
How are Cloud Native Companies different?
Okay, so we’ve talked through the stance of Cloud Native and what it is. But that was really only groundwork so that we can discuss what it all means for you.
Because, as a software engineer we want to tailor our skillset to that of our future employers. If the future is Cloud Native then as a software engineer we need to cultivate the skillset to compliment what is required. But, in order to do that we need to know what things look like in Cloud Native company. What are the key differences in the way cloud native companies operate? Let's get to this question now.
And let’s start with a big area that is impacted in a Cloud Native organisation and that’s: Architecture.
In a typical on-premise enterprise architecture is centrally governed. That means architects make decisions that are then given to engineers, and engineers follow these instructions to the letter. However in most Cloud Native companies decision making is decentralised and shared amongst teams who are more free to architect their own solutions. The devolution of central architecture requires individual teams to take on a greater burden of architecture, which is both liberating, but also an additional workload. It means software engineers need to write code, but also architect it, given the huge list of cloud resources to choose from.
Another big area that is impacted is: Operations.
In a Cloud Native company it's more likely that teams are operating the philosophy of "you build it you run it". Which essential means that the engineering team that writes the code is also responsible and on-call for their application. Being on-call is an additional time burden, but it also means you need to know monitoring tools, have solid communication and a broad skillset to resolve production issues.
As you can see, there are not only some cultural differences but critically the skills are different. Cloud Native Software Engineers need to know more. They have to contend with their chosen programming language, their problem domain AND all the latest cloud technology.
Do you want to become a Cloud Native Software Engineer?
And that’s it for today. I’m hoping that gave you an insight into what it means to be a Cloud Native software engineer and the differences that Cloud Native companies have with their agnostic, or on premises counterparts. Whether you do or don't want to embrace Cloud technologies it's important to be aware of the changing times so you can make a decision that's write for you.
And one last thing before you leave... I created this website to help Software Engineers understand and navigate the landscape of Cloud Native Software Engineering. If that’s something that is useful for you, make sure you sign up to the email list.
Being on the list means you’ll get new articles in your inbox every week. And the list is designed to keep you up-to-date with the latest trends and movements in Cloud Native Software Engineering.
Question: Are you thinking of becoming a Cloud Native Software Engineer? If so, I’d love to hear your thoughts and questions in the comments below!
Top comments (0)