Stop Certifying and Start Building Cloud Native Applications

The motivation for adopting a public cloud for applications is to go faster, save money or innovate by using features only the cloud can offer.

However, the cloud is often less reliable, more expensive and less secure than before when you build applications with a traditional approach.

Cloud-native development uses techniques that make applications more reliable and more secure than the cloud infrastructure on which they run. Applications become more cost-efficient when you can leverage abstractions that best use resources.

Don’t think of cloud-native applications just in terms of technology. While containers, microservices, Kubernetes, or serverless are valuable tools for building cloud-native applications, they do not define cloud-native.

Technologies can be abstracted away until you are ready to explore them more deeply. Don’t get hung up on learning Kubernetes or a whole cloud platform. Build applications using a few services, get them running, iterate and improve.

Take a step back. If you are cloud-native, you are in the world of distributed systems. You will form applications out of autonomous, loosely coupled components communicating with messages rather than sharing state.

Are you sure you know where the boundaries between components lie? Do they have a single responsibility and a single reason to change? Although deploying independent microservices is one approach, sometimes it can be more effective to start by deploying a modular monolith that can be broken up later.

When you identify a component that needs to change, scale or fail independently without impacting others, it is time to break it into a microservice.

However, once you have multiple services, how will they communicate? Via events or APIs, synchronously or asynchronously? How will you secure those communications? What data storage and messaging will each component consume, and what services does your cloud provider offer to make your life easier? Remember, the finer the granularity, the more flexible but also, the more complex the system.

Think about how you will build, package, deploy and run each component and how that can be automated. How will you observe the system and detect and correct problems? Be lazy, and don’t spend your time on toil. No one wants to be woken up at 2 am to fix an issue or spend the day running the same commands for the hundredth time. Get it automated and get back to delivering value.

The best way to learn how to run 5km is to run and walk shorter distances and gradually increase the running. Similarly, the best way to learn how to build cloud-native applications is to create a small one and then grow.

Work with others, define a problem, experiment, build a solution together and move on. Repeat with other people, share your knowledge and learn together.

Always prioritise testing. It is the only way to maintain momentum. Know what your application is meant to do and what it is doing, and most importantly, why. Give yourself the confidence to make changes and make those changes rapidly. You will enjoy the productivity of cloud-native development.

You will be vastly more valuable with the practical experience of building half a dozen small cloud-native applications, even if you throw them away. You can pass every certification you like but do you want the first time you put theory into practice to be on your employer’s newest business-critical system?

• Cloud-native is different and distributed.
• Cloud-native is not defined by technologies.
• Cloud-native should be fast and fun.
• Cloud-native benefits from repeated hands-on learning; the best way to learn is with others.