Many companies want to move their systems to the cloud to reduce costs and release faster. Let’s see the usual steps and their advantages.
Microservices
Big applications are difficult to handle because dozens of people work on them in parallel and they may block each other. And it may take lot of time and effort to reach a point when it is stable enough to be released as different teams may have to re-test all the features.
These applications can be broken down into smaller services so developers can work independently without affecting each other and every feature or bug fix can be released separately without impacting others. This way we can change from releasing every few months to do it multiple times per day, delivering value to market faster while reducing costs.
Streaming
Data is usually stored isolatedly, it may not be refreshed regularly and to access it we have to figure out how to interact with the system managing it. This blocks business users from real-time decision making as they may have to wait hours to get data reloaded, and it costs lots of time and effort to figure out how to connect applications created by multiple teams with different technologies.
We can instead immediately propagate data across systems so any consumer can use it without effort. This way they don’t need to know anything about the data producer and can instantly process it without having to wait for an overnight job copying it from one system to another.
Continuous integration (CI)
As we now deploy thousands of services we can automate processes and add extra checks to ensure code doesn’t have obvious issues, all tests pass, etc. There are multiple technologies that detect any code change, trigger all deployment steps and trigger alerts if they find any issue.
Continuous delivery (CD)
Once the deployment processes are automated for an environment we can adapt other processes so changes flow to the live environment as soon as possible and almost without human interaction. We can tune the code branching strategies and approval processes so, once the standard checks pass, new changes are automatically released instead of waiting for days and coordinating with multiple approval and release teams.
Containers
We have to be confident that services will work the same way on every environment and independently of minor infrastructure changes. To do so we can package them into units that contain a reduced version of an operating system. This way we can be sure that applications will work the same way on every environment and are protected from misconfigurations affecting individual instances.
Container orchestration
Once we have decoupled applications from the machines they run on, we can go one step further and make it really easy to use as many copies of them as we want to and change it based on our needs, so we only pay for them when needed. For example we may have higher usage on the evenings or on special events like Black Friday, and it makes sense to only pay extra on those moments. We can use many tools like Kubernetes to configure minimum and max usage, use spot instances to get them when they are cheaper, etc.
Functions
Some features don’t have to be available 24/7, e.g. some reports that only run at month end, and it doesn’t make sense to have their services running all the time on multiple servers. We can instead provide their code to a cloud provider and use technologies such as AWS Lambda to configure when and how to run them.
Cloud services
Some services don’t have to be implemented anymore as cloud providers are already offering them, and the same for the infrastructure. There are chatbots, AI modules, … already trained and ready to use, so it is not needed to hire a team of experts to create them for us. And the same for databases, queues, … that can be deployed and maintained with just a few clicks instead of needing operations teams to configure and maintain them.
Infrastructure as code (IaC)
As teams grow we have to scale the infrastructure to support new needs and it is good to automate its configuration so we can quickly replicate it in another region or cloud provider in any issue happens. We can configure the infrastructure in scripts that are deployed automatically like if it was application code and add to the pipelines checks to ensure there are no issues like incorrectly configured network rules.
DevOps
Companies used to have separate product teams that built applications and operation teams that deployed them and maintained the infrastructure. Many of the deployment and infrastructure steps are being automated, blurring the lines between those teams and many people are doing both types of tasks. It requires a culture change as teams are being combined and working together to achieve common goals, and both profiles are learning from each other as Ops are learning about coding and automation and Devs about infrastructure and releases.
DevSecOps
The attack surface is a lot bigger as we have to protect from hackers hundreds of services, manage thousands of dependencies, consider new services like online storage, … You can find more about it here. It requires a lot of time and effort to do it manually so we can automate many of these checks as part of the deployment pipelines as explained here.
Summary
There are multiple steps to move to the cloud, from breaking down services to make them easier to deploy to culture changes so teams can work better and faster, and both applications and infrastructure can be deployed automatically as part of the new processes. I hope you find this list useful, let me know in the comments if you want to know more about any of those topics and I will prepare specific posts about them.
Consultant and security champion specialised in Java, with experience in architecture and team management in both startups and big corporations.
Disclaimer: the posts are based on my own experience and may not reflect the views of my current or any previous employer
