Taming Microservices With Cloud Foundry and DevOps

As we all know, Microservices have some benefits. In summary: They encapsulate logic that belongs together, enforce the cohesion and fit perfectly into an agile development process since a well-designed Microservice architecture is able to mature over time without putting much effort on this. Another pro is that each service can be implemented with the best fitting technology. Because of the smaller service size it is much simpler to rewrite a service using a new technology once you recognized you’ve made a silly choice. See this blog post for a closer explanation of the benefits of microservices.

These benefits are dreamful for developers but once it comes to operation, it becomes a nightmare. Tons of small applications implemented in different programming languages, frameworks and last but not least each one uses a different database technology. So when you decide to go with Microservices make sure you can handle those challenges. Let’s have a closer look on how this can be done.

Table of Contents

• DevOp – You build it, you run it!
• Cloud Foundry – Yes you can! No excuse!
• The Developer’s Responsibilities
• What about Docker?
• Conclusion

DevOp – You build it, you run it!

DevOp is currently a strong and popular movement. I would summarize it like this: It refers to the principle of establishing cross functional teams which are responsible for design, development and operating of applications. This principle was promoted by amazon with their popular mantra “You build it, you run it”. So, in my opinion, the term DevOp refers to a team and a culture not to one single person.

Cloud Foundry – Yes you can! No excuse!

Operating heterogeneous applications usually requires deep operational knowledge. When an organization puts the responsibility to operate applications into the same team that developed the applications this team probably will protest at first. Because they think that additional responsibilities cause more work and stress.

Cloud Foundry’s aim is to take the wind out of the sails of those protests. Using Cloud Foundry each developer can go to the Cloud Foundry marketplace and pick technologies he wants to use. A single command later, the developer has its own instance of the required database type, message queue etc. Once the databases and other “backing services” are in place, the apps itself can also be deployed and scaled with also a single command.

Cloud Foundry encourages a DevOps culture by enabling developers to deploy and run their own applications. They don’t have to talk to an operations department anymore which reduces wasteful work dramatically.

But what Cloud Foundry can’t do is to take a monolithic not- cloud ready application run them highly available and scale them when load increases. To make the best use of Cloud Foundry, the developer must consider a good design when building their applications.

The Developer’s Responsibilities

To leverage Cloud Foundry and Microservice architectures, developers must not only care about programming, they must also care about designing the architecture. This knowledge must pre present in each DevOp team and in the best case every developer is able to join such discussions. Why? Simply because there isn’t one architecture that is the right one. With every architectural decision trade-offs are made and the more people discuss these trade-offs, the better it is and the less surprises will arise. When you establish a DevOp team for application development, maintenance and operation, make sure the following skills are present in that team:

• Architectural Knowledge: Each developer in that team should be eager to be a better architect. The SOLID principles should be known, DDD should be known, CAP- Theorem should be known, the concept of high cohesion and low coupling should be understood very vell.
• 12 Factor principles: In order to deploy and configure applications on Cloud Foundry – or on a PaaS in general – the 12 factor principles should be well understood within the team. They give you some guidance in how application should be written to be deployed and configured with ease.
• Integration Testing: Running integration tests with a Microservice architecture is much harder than running integration tests on a monolithic application. But still those tests are very important and in a Microservice architecture they might  even be more important. Simply because each Microservice must be integrated in a much more complex environment, consisting of a bunch of other services. Make sure the DevOp team knows which techniques exists, how to implement them and what the trade- offs are.
• Continuous Deployment: Whether it is Jenkins, Concourse CI, Spinnaker or something else, make sure the DevOp team knows at least one CI tool and how to setup deployment pipelines.
• Pair Programming: Pair programming has two major benefits: it transfers knowledge and it extends the attention span so that in sum the attention span of the two devs is longer than it would be if they worked alone. Sitting with two devs in front of one laptop solving one problem sounds simple at the first glance but in fact it is not. Effective pairing requires the ability to take the perspective of your pair and to be able to explain what you are thinking, constantly!
• Test Driven Development: Imagine you write a module/class/lib. How do you test whether the piece of code works? Probably you start the debugger and call the method you’ve just written or you write a piece throw away code that executes your new written method. TDD is a methodology to do this in an organized way. When composing your DevOp team make sure there is a lot of TDD knowledge in this team. The benefit of writing tests firsts must be well understood as well the distinction between white box and black box tests.
• Product Mindset: Make sure the DevOp team doesn’t think they are working on a project. It doesn’t matter whether they are working on application with a GUI or on applications with an API, each Microservice should be considered as a product and the team is responsible for the whole lifecycle. Documentation, operations, gathering user feedback and so on.
• Curiosity: Because Microservices are small and can be rewritten in a small time period and because each Microservice can be built with other technologies, we are not longer cursed to use the same old tech for decades. Make sure the DevOp team is eager to learn new technologies.

What about Docker?

There is no blog post about DevOp and Microservices without Docker. So let’s talk about Docker. Docker provides you an easy way to setup an environment and then take this environment and start it on any Linux machine. The point is, this is done using containers and not virtual machines. Containers starts much faster than virtual machines and has a much smaller footprint. Another thing that Docker allows you is to extend and share your containers very easy.

In contrast to Cloud Foundry Docker doesn’t provide you an orchestration of your Microservice architecture. This means you must take care that the right Docker container runs. To automate this there are other solution like Docker Swarm or Apache Mesos. Those infrastructures provide you more flexibility than Cloud Foundry but come with much more responsibility. There is no marketplace where you can get turn-key ready database setups with one command. Docker is an option for mature teams able to deal with more responsibilities.

FYI: Newer version of Cloud Foundry offers a simple way to also specify a Docker container that should be used to run your application.

Conclusion

A team with a DevOps mindset and knowledge should be able to tame even a larger Microservice architecture. Using Cloud Foundry and applying some basic principles will transform even skeptical developers into a high performance DevOps team.