With the update of our website we’ve also switched the focus of our company to Cloud Native software development. And we’re not the only company to do so. The ‘Cloud’ is a popular buzzword and are we just jumping on the bandwagon?
As popular as the term Cloud is, so is the joke that the Cloud is ‘just someone else’s computer’
Yet we take the term quite serious. Especially when looking at the term Cloud Native. There is a lot more to it than just running your site or application on computers owned by someone else. What it means is also highly related to DevOps.
DevOps
Similar clear in IT is the shift to DevOps. And seasoned IT engineers can be similar cynical about that term. With DevOps we make sure the staff maintaining a site or application is also the team that develops the application. It is not uncommon now for companies to just put the ops people and dev people in the same team and call it DevOps.
If that is all, being cynical and claiming that we often already did this in the nineties and just did not have a word for it would be valid. And frankly, placing dev and ops people in one team does indeed often help. Only in our view this is not (only) what DevOps is about or should be about.
One of the key aspects of DevOps is that one team is fully responsible for making sure that an application runs smoothly and adapts rapidly. The more a team is reliant on another team or service, it’s success is also dependent on that other team or service provider. Therefore, either you do it yourself, or rely on a service that is highly reliable and delivered very quickly. To make this feasible you do not want your team to host your application the old fashioned way and arrange for (physical) servers, data centers, change failing hard drives etc.
This is where the Cloud and Cloud Native come into play. The services the cloud provides are the infrastructure that your DevOps team needs, does not want to spend time on providing themselves and can be consumed almost immediately and automatically. Whether you still build your application on virtual servers or containers, consuming them from a Cloud provider has to be quick and automated.
Automation is another key feature of DevOps. The team wants to spend as little time to the operations part as possible. They are responsible, but having people dedicated to running the application is not what we want. The operations part is to be automated. So basically the operations part is really also a development job. You develop the system which should be self healing, scale automatically, run with very little human oversight and even changes are automated.
This can be done with virtual servers and scripting that patches the operating systems of these servers, installs patches and new releases etc. There is however another approach: the Cloud Native approach. This approach relies heavily on containers that run on a platform provide by the Cloud provider where the DevOps team doesn’t even get to deal with virtual servers anymore. The application runs in containers, storage and databases are provided ‘as a service’ and provisioning is automated. Using these building blocks you can build/develop the operation of your application on a Cloud platform to run reliably with very little intervention. So to do DevOps well, you need a Cloud platform. This by the way does not have to be a public cloud! Running Cloud Platforms on-premise such as VMwares Tanzu or Red Hats Openshift enables companies to provide these cloud building blocks without having to move your application to public cloud provider.
Cloud Native
The term Cloud Native means that the application is built or adapted to run on such a Cloud platform. If you adhere to the principles, your application will run reliably with very little intervention, can be changed rapidly and reliably to adapt to changing needs. There are well known guidelines known as the 12 factors. These factors deal with items such how to to build the application, how the build and release process is done, how to prevent deviation between what was in test and what ends up in production etc. There is an initial investment to adhere to these factors, but if done correctly and if you properly automated the entire build test en deployment pipeline in a CI/CD pipeline you end up with a system that makes it so reliable that you get comfortable providing changes whenever ready. Deployment should be boring.
The result is much faster development, rapid changes, applications that run reliably with less to zero downtime that can scale easily without hassle and having to wait and rely on others.
There is so much more to this than what should be in a blog post. I’ve been lucky to have worked with some of the best in the field in the past few years. Experience that taught even a nerdy techie such as myself that aspects such as the way of working, UX are just as important as the technology. But I hope to have shared some insight into why we changed the focus of our company and jumped on the bandwagon of Cloud Native and DevOps.