Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Developing Microservices for the Cloud

Developing Microservices for the Cloud

This item in japanese

When working with Microservices pushing them to the cloud, people often find it difficult to understand the new architecture, it’s a paradigm shift, Daniel Bryant explains in a presentation at the Microservices Conference in London sharing his experiences of what he has found useful working with microservices in the cloud during the last five years.

As a help when designing and implementing cloud microservices Daniel, Principal Consultant for OpenCredo, has created a checklist with the DHARMA principles, comparing them to the SOLID principles used in object-oriented development.

Documented (just enough), means for Daniel lightweight documentation, just enough to get started. It's about creating a map for developers and describing the components including their purpose. It should also highlight operational risk and document how the system is designed.

Highly cohesive and loosely coupled, which for Daniel is about architecture for things that are hard to change, fundamental things, not only at the code level but at all levels.

He defines three key things to architect for:

  • Encapsulation, e.g. Single Responsibility Principle (SRP), Separation of Concern and other similar principles.
  • Scalability, a common reason moving to the cloud.
  • Comprehension, with time to market really important, companies often does well because they can innovate fast, increasing their competitive advantage.

Automated from commit to cloud, meaning continuous integration deployment and delivery. A key thing is getting artefacts to a cloud-like and realistic environment as early as possible, verifying that they are working correctly. Daniel highly recommends performance testing with realistic data to avoid that performance slowly decreases without anyone noticing until at a later time when it passes a critical threshold. Working with a microservices pipeline, Daniel notes that if you can’t deploy services individually you probably are not creating microservices. You have to be very careful avoiding creating a distributed monolith; it may cause a lot of pain in terms of speed of change.

Resource aware, meaning you have to understand that the cloud is fundamentally a different platform. Everything in the cloud is over a network; one example that has burnt Daniel is reading data from a virtual hard-drive which is much slower compared to a laptop, making performance drop drastically.

Daniel notes that mechanical sympathy is important; you have to understand the fabric underneath the cloud, the most important parts being virtualization and networking principles. Basically it’s about thinking and acting operationally, taking responsibility for what you build and deploy.

Monitored thoroughly, and everything should be monitored. Getting visibility into what’s happening in a system is essential in a cloud-like environment, including metrics from a business point of view. Compared to a monolith where tracing a request normally is quite straightforward, tracing through microservices sometimes can be very hard e.g. when the request passes several services. Creating a correlation id that follows the request can in these cases be of great help.

Antifragile. The opposite of fragile is not robust but antifragile, but Daniels stresses that a system must be robust first thus avoiding cases where a system scales perfectly but is still failing.

Distributed computing principles are important, with a lot of potential problems, but also a lot of solutions, and Daniel sees too much of reinventing the wheel because of developers not knowing about existing solutions.

The Microservices Conference is the first on the subject arranged by Skills Matter, in London.

Rate this Article