“Microservices should not be used if the organization is not embracing DevOps principles”
No software architect can resist the temptation to talk about their experience with microservices. We launched an interview series with experts who talked about the benefits and challenges of microservices, when people should not use them and what impact they have on an organization. Our third interviewee is Daniel Bryant, Chief Scientist at OpenCredo and speaker at the upcoming JAX London.
In this interview, Daniel Bryant, Chief Scientist at OpenCredo and JAX London speaker, talks about his likes and dislikes about microservices. Here are his answers.
JAXenter: Why did you start using microservices?
Daniel Bryant: I first started using an architectural pattern that was similar to what we now call microservices on a project in 2011. The reason we chose to use a service-oriented approach was due to the early identification of separate areas of functionality within the overall requirements. We also had several teams involved in creating the software (spread across the UK and also Europe), and we believed that dividing the system into well-defined services with clear interfaces would allow us to more efficiently work together on the project.
The development of separate services, each with its own interface, functionality, and responsibilities, meant that once the teams understood and designed the overall system-level requirements and interactions, we could minimise the need for constant inter-team communication. Well-defined service contexts and less communication meant that we delivered valuable software more quickly than if we had all been working (and coordinating) within a single codebase.
JAXenter: What is the most important benefit of microservices?
Daniel Bryant: When a microservice architecture is implemented correctly, the most important benefit is agility — in particular, the ability to rapidly change a system without unintended consequences. This means that as customer requirements (or the market) changes, the software delivery team can quickly react and adapt the software to meet these new requirements, and do so without worrying that a small change will create unforeseen issues (or require large amounts of testing to prevent regression).
The properties of a microservice-based system that enable this benefit include:
– Understandable and well-defined cohesive services based around a business function (i.e. bounded contexts)
– Well-defined service interfaces (APIs),
– The ability to make assertions about functionality throughout the system stack, at a local and global level (e.g. component tests, contract tests, and end-to-end tests)
JAXenter: Have microservices helped you achieve your goals?
Daniel Bryant: The use of the microservice architectural style has definitely helped in several projects I have been involved due to the reasons mentioned in the previous answer. I work mostly as a consultant, and so am in the privileged position to see lots of different projects. Although microservices aren’t a panacea (and I haven’t used them in every project), they are a very useful pattern in my ‘architectural toolbox’, and I have used them to help teams I work with understand fundamental software development paradigms/qualities like coupling and cohesion.
When a microservice architecture is implemented correctly, the most important benefit is agility.
JAXenter: What do you think should be the optimal size of a micro service?
Daniel Bryant: As a consultant, I like to say ‘context is vital’, and so I believe there is no optimal size for a microservice. My recommendations are to keep services focused around a cohesive business function (e.g. user service, payment service etc), ensure that the team can use a ubiquitous language within each service (i.e. a concept within a service means only one thing – for example a ‘user’ within a payment service is simply an identifier for a payer), and make sure that a developer can readily understand the service context and code after a couple of hours of investigation.
JAXenter: What is the biggest challenge of microservices?
Daniel Bryant: One of the primary challenges is not getting caught in the hype. Resist the temptation to build everything as a microservice — it is simply an architectural style, and like all such styles, has strengths and weaknesses.
Another primary challenge includes testing — microservice systems inherently have more dependencies that must be managed, and testing the interactions between services can be challenging. This is why I have been working with the SpectoLabs team on the development of various tools to support the testing of microservice-based systems. We have an open source ‘service virtualisation’ and API simulation tool named Hoverfly, which includes a JUnit Rule for use within a typical Java testing process and CI pipeline. My colleague, Andrew Morgan, will be talking more about these challenges and associated tooling at JAX London in October. We’ve also received great feedback on Hoverfly so far, and I would be very keen to hear more comments from the JAX readers!
JAXenter: What technology do you think is the most important as far as microservices are concerned?
Daniel Bryant: In my opinion, microservices are technology agnostic, and the pattern can be applied with any programming language. Implementing microservices does, however, increase the need for a good platform i.e. deployment/runtime fabric, such as Cloud Foundry, Kubernetes or AWS EC2. Although I like to encourage developers to cultivate ‘mechanical sympathy’ and understand key properties of the deployment fabric, I also believe they shouldn’t have to be overly concerned with things like process scheduling, configuration and service discovery.
Container technology, such as Docker, rkt and LXD, is also quite complementary to microservices, and these homogenise the deployment and runtime packages, but I don’t think this is essential for microservice development.
JAXenter: How much do microservices influence an organisation? Can they leave the organisation unchanged?
Daniel Bryant: If the spirit of the microservice architectural style is fully embraced — creating services based around business functionality — then the potential impact on an organisation is massive (particularly for a traditional enterprise), as business teams will have to re-organise away from horizontally functional silos (e.g. finance, marketing, PMs BAs, developers, QAs) to vertically integrated cross-functional teams (e.g. the conversion uptake team, or the user signup team). Many people have already written about Conway’s Law, and so I won’t cover this here, but I’ve witnessed the results enough time to know that this is a real thing. In fact, it’s worth noting that many of the pioneers in the microservice space started developing architectures that we now recognise as microservices because of business requirements for agility, team autonomy and decreased time-to-market.
Microservices are technology agnostic.
Many people have already written about Conway’s Law, and so I won’t cover this here, but I’ve witnessed the results enough time to know that this is a real thing. In fact, it’s worth noting that many of the pioneers in the microservice space started developing architectures that we now recognise as microservices because of business requirements for agility, team autonomy and decreased time-to-market. This wasn’t necessarily a top-down edict to componentize systems like there was with the traditional SOA approach.
Resist the temptation to build everything as a microservice.
JAXenter: When should you not use microservices?
Daniel Bryant: I get asked this question quite a lot, and it is difficult to give a definitive answer. However, situations where microservices may not be beneficial include:
– Working with a simple application domain
– Developing software with a small number of people in the team
– No problem/solution or product/market fit e.g. you are a startup that is still exploring your business domain and how to make money
– When the organisation is not embracing DevOps principles (i.e. see Martin Fowler’s MicroservicePrequisites article).
JAXenter: What are your guiding principles in the division of an application into microservices?
Daniel Bryant: Firstly, make sure you understand your domain. I am a big fan of Domain-Driven Design, and so readily recommend the use of Context Mapping in order to fully understand (and model) your application domain. I’m also finding the technique of Event Storming increasingly useful to help build a dynamic (event-driven) picture of the system over and above the static picture provided by Context Mapping. Once you have modelled your domain, I typically find that natural service boundaries emerge.
Other techniques include the use of code analysis, both in terms of complexity (e.g. cyclomatic complexity or more crudely, lines of code) and churn (e.g. code change over time, as shown by VCS logs), and the identification of natural friction points (e.g. interfaces, potential seams, locations where data is transformed). Adam Tornhill’s book ‘Your Code as a Crime Scene’ is an excellent resource here, as is Michael Feather’s ‘Working Effectively with Legacy Code’.
JAXenter: Should every microservice be written in the same language or is it possible to use more languages?
Daniel Bryant: I like the idea of polyglotism, both at the language and data store level, as this embraces my personal philosophy of using the ‘right tool for the job’. However, context is again key here, and if an organisation is struggling with understanding core architectural patterns or using (and operating) a single language platform, then adding more into the stack will only cause more trouble.
JAXenter: What aspects should you take into consideration before using microservices?
Daniel Bryant: As a consultant, I like to conduct organisational ‘health checks’ before embracing any new architectural style or software development technology. These health checks would typically cover things like:
– Is the business/organisational strategy well understood i.e. do the development team know the overall mission and goals, and also understand why they are doing what they are doing
– Is the organisation’s leadership well-aligned and are teams capable of working together effectively; is the organisation ‘operationally’ healthy – are they embracing ‘DevOps’ principles, and do they have a well-functioning continuous delivery build pipeline
– Are developers/QA being well trained on architectural patterns, domain modelling, and technologies;
– Is there a process for feedback and learning e.g. retrospectives, career development programs etc.
Thank you very much!
Daniel Bryant will be delivering one talk at JAX London which will focus on the benefits of empathy, which he learned from working on a large variety of software projects over the past ten years.