Changing Times

These days, more and more businesses and enterprises are (finally!) embracing the cloud and moving their applications to cloud providers like Amazon AWS, Microsoft Azure, or Google Cloud. 

But just moving your applications to cloud infrastructure ("lift and shift" as its commonly called) is simply not enough. Sure, it would be nice if your applications magically inherited all the properties of the cloud just by running there. Unfortunately, that's not the reality. 

  • The cloud is elastic. It is the complete opposite of static! The amount of resources available to your application, like computing power or storage, can grow and shrink at any given time.
  • The cloud is on demand. It's very easy to rapidly provision new resources for use. Need more computing power, no problem! You can create a new server, through an easy to use interface, with a few simple clicks. Or even better yet, the whole process can be automated. No humans required!
  • The cloud is infinite! This one is a bit of a fallacy as things are not truly infinite. However, for all intensive purposes, you can consider resources in the cloud as infinite. You shouldn't ever need to worry about running out of things like space or compute resources (unless of course you're running a company with the same scalability problems as Google). 
  • The cloud is ephemeral. Resources in the cloud are ephemeral or short lived. Compute resources, like servers, can be created from scratch, started, made to run some application code, and shutdown all in a matter of hours.

Developing Cloud Native Applications

Whether you're building a new application or modifying an existing one, utilizing the cloud to its fullest almost always requires modifications to both your application and most importantly, your way of thinking.

  • Cloud native applications should be stateless. Due to the elastic nature of the cloud, you can't rely on a resource always being around. This means you have to really think about how your application stores state or better yet, avoid storing state all together! Statefulness also has a direct impact on your ability to scale your application. You can run 2, 3 or even 100 instances of a stateless application and all instances are the same. However, a stateful application must store its state in an external data store such as Redis so that all instances see the same state.
  • Cloud native applications should be discoverable. Similar to the same reasons your applications need to be stateless, they also need to be discoverable. If a new resource becomes available, how will your application know that it exists? Service discovery providers like Netflix Eureka or Consul become a key component of building cloud native applications.
  • Cloud native applications should be distributed. The on demand and "infinite" nature of the cloud makes it significantly easier to scale an application when demand increases. But scaling your whole application when only the most resource-intensive areas of the application need to be scaled, doesn't make sense. That means, as software engineers, we have to move from thinking about a single centralized, monolithic application, to multiple individual services that form one application.
  • Cloud native applications should be fault-tolerant. In a distributed system, failure is not a matter of "if" but "when". Design with failures in mind and provide a way to gracefully handle errors such as returning a default value.

The Cloud is a Game Changer!

Despite all the crazy marketing, the cloud really is a game changer. The above list is by no means comprehensive but it should at least get you thinking about how the cloud is different than your traditional deployment environment. And if you continue to use the same principles/techniques/patterns in your applications, you'll never fully realize what the cloud has to offer. 

So, ask yourself, what would I need to change in my applications to be cloud-native?