Embracing the cloud

Glenn Bostoen
5 min readAug 27, 2018

The complexity of applications is rapidly increasing because customers demand more. They desire real-time, highly responsive applications that they can use everywhere. If you develop this in a single-tiered application — a platform where the user interface and data access code are combined into one — it becomes tough to achieve.

A developer can have the feeling of climbing a mountain when getting introduced to a codebase of a monolithic application.

Why? There are numerous issues with monolithic applications:

  • Code complexity grows despite the efforts of employing all best coding practices. A new person joining the code base could have a steep learning curve
  • Changes are expensive because of the growing code base and dependencies, which makes changes slow to implement and even harder to deploy or test
  • Scalability resides only on the application level, which isn’t as fine-grained as we want
  • Continuous integration & deployment becomes difficult because every code change results in the whole application to be tested and built
  • System failure, the smallest issue introduced could result in the whole system failing

We have tackled this by moving away from monolithic applications that contain all logic and shifted to a more service-oriented architecture (SOA) with microservices. Microservices are easy to grasp and lower the complexity from a developers point of view because the amount of code residing in it is low. Some people explain a microservice as something that should be understandable in a day or two. A microservice architecture allows us to decouple the logic that would otherwise reside in one big code base, where the boundaries would not have been so strictly defined. Independent services mean they have their dependencies and framework depending on the problem at hand.

Microservices give us autonomy in a way that wasn’t possible with monolithic applications. It gives us as an independent team a high degree of design autonomy — choosing which technologies and patterns to implement a microservice-, and the ability to update or redeploy a component independently. This way of working allows us to deliver features at a higher velocity as developers.

Benefits of microservices

  • Single responsibility: a microservice should do one thing and one thing only. Its design should try and avoid any dependency on any other part of the functionality
  • Data & state should be isolated: a service owns its data and its state. It does not share ownership for the same with any other application or its part
  • Independent Deployment: is a cumulative effect of both the points above. This goes hand in hand with continuous deployment
  • Technology Adoption: is more comfortable achieved while taking care of the first two points. The introduction of new programming languages or framework becomes easy because the introduction of updates has no impact on any of the existing modules. The beauty here lies in the fact that you could have two different versions of a microservice in two different technologies, which makes it extremely beneficial

Docker accelerated the adoption of microservices. It allows us to package our code as an immutable artefact, so we have an identical application in all environments. At the same time, it provides the capability to run our service in isolation with its dependencies (empowering technology adoption). Unfortunately, this benefit gets lost when switching back to a containerless environment.

The whole microservices philosophy only works if you have a platform that abstracts away the infrastructure and makes full benefit of containers. If you don’t have to think about the underlying infrastructure or worry about services interfering with one another. Sadly, we still see that many companies map microservices in an old-fashioned way; being one application with a dedicated virtual machine. Committing a whole virtual machine isn’t flexible as the service gets capped by the amount of CPU and memory provided by the virtual machine and could lead to overcapacity. The other end of the spectrum is just bundling all those microservices back into one and deploying it on a virtual machine, but this means you are coupling your microservices back together, which could potentially lead to issues regarding dependencies.

Within In The Pocket, we fully believe in container orchestration and are entirely focused on making use of Platform-as-a-Service (PaaS) powered by Kubernetes. Kubernetes is an open-source container-orchestration system for automating deployment, scaling, and management of containerised applications. This makes it a lot easier for the operations team to keep the infrastructure running. They only need to worry about the layers up to Kubernetes, and the developer can focus on the application aspect. This thought is in line with major companies like Google and Amazon. If we look at Amazon, they have the following to say:

“Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it; you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service”

Werner Vogels, CTO Amazon

We’re running our containers on top of Google Container Engine (GKE), which gives us even more flexibility regarding scaling and upgrading. Google fully manages the underlying infrastructure. For our customers, we’ve already lifted their infrastructure from traditional hosting partners to GKE.

Managed container orchestration is only one aspect I wanted to highlight in this blog post, but it is just the start of what cloud providers have to offer. There are a lot of out-of-the-box services like:

  • Managed Caching services
  • Key management system
  • Infinite storage
  • Managed SQL which even supports global scaling if needed
  • Virtual private cloud spanning the globe

Conclusion

Microservices are here to stay, it’s a paradigm shift we have seen in the last couple of years, and it’s not going anywhere. We have to embrace it if we want to keep innovating. However, all this would not be possible without the services that cloud providers provide us.

Originally published at inthepocket.com.

--

--