Microservices seems to be the buzzword of the moment, with more and more companies opting to ditch their monolith in favour of the decoupled approach. A 2018 study by RedHat found that close to 70% of respondents said they were using microservices for both new applications and for re-architecting existing ones.
However, although the trend towards microservices, a method of software development that allows you to develop features separately using polyglot programming in multiple environments, is growing, microservices is not right for every business or for every application.
Moving to microservices from the traditional monolithic approach to application development means thinking about how you can break up this large application into smaller components.
Breaking up is hard to do
Asena Hertz, Senior Product Marketing Manager at Turbonomic, explains that breaking-up applications into loosely coupled services has the benefit of allowing developers to work independently, in parallel, on features that make up an application. She says that one team can work on the search functionality while another team is working on a more streamlined checkout or payment processing experience.
"Containers make it possible for these application services to be decoupled, significantly reducing risk that comes with tightly integrated monolithic applications that used to require months or quarters for new features to be released. That's great for developer speed," Hertz says.
Pratik Parikh, Director of Product Marketing for Business Network at OpenText, believes that the best business argument for increasing investment in microservices is usually the opportunity for an organisation to modularise the complexity of its enterprise ecosystem. Microservices enable businesses to focus more on enterprise services, which contributes to the overall operations of a unified ecosystem, Parikh says. "This allows organisations to realise the benefits of scalability and nimbleness that most modern cloud platforms offer."
It is important for C-suite executives to understand the value of moving towards a microservice architecture, since the cost of resources and time for the transition will be high, according to Mark Levy, Director of Strategy, Software Delivery at Micro Focus. He says that implementing microservices will increase operational scalability and deliver improved system resilience while enabling a faster time to market.
Faster innovation, less risk
"Microservices enable companies to innovate faster with less risk," he says, but adds: "The C-suite needs to understand and support the necessary changes. It's more than a technical approach because in order to receive the benefits of a microservices architecture, the organisation must transition to a DevOps culture of continuous improvement."
Levy explains that microservices will change the way teams communicate, and teams will have to be re-organised to map to service boundaries. All required competencies should be contained within the team. A DevOps culture of shared responsibility alongside fostering a collaborative environment is an absolute requirement.
For Australian enterprise software company Atlassian, the move to microservices has been very successful, improving the speed of its development loop and increasing team morale, among other things.
CTO Sri Viswanath explains that this success was driven by the company's ability to plan for and implement three important components: setting clear goals, investing in tooling and consistency measures, and considering the people and culture impact.
Viswanath adds that microservices is not right for everyone and now may not be the right time for your company to embrace it, so it is important to outline exactly why you're considering the move - cost, driving efficiency due to several products sharing common functionality, or something else.
"For Atlassian, the move made sense because we were running a suite of products that shared a lot of common functionality, and we had the team structure and culture to make it a success," he says. "However, if you're a smaller company only working on one or two products, the investment in microservices isn't likely to pay off in the near term. Stick to the monolith because your smaller size probably means that your engineers are already talking to each other frequently and benefiting from close alignment and shared responsibilities."
A culture of trust and autonomy
The monolith is often easier because it provides a common way of interacting with it and building on top of it. That all changes with microservices, as each service team has a lot more flexibility in how they build and maintain their service. Viswanath says that if you don't establish consistent tooling and/or processes early in the process, you're likely to have a lot of chaos later.
"At Atlassian, we wanted to give our teams autonomy, but with guardrails. We built tools that gave visibility to all the microservices across the company; we helped define the tech stacks, including technologies, libraries and design patterns for engineering; and we rolled out an operational maturity model that ensured that the quality across all the microservices was mapped to a consistent, high standard," he explained.
A move to microservices requires an understanding that it is as much about the people, teams, and culture, as it is about the technology. "This is often overlooked or downplayed in the discussion about microservices, but is often the hardest part to get right. If you're not prepared to deal with the people-side of the switch to microservices, you should really reconsider making the change," Viswanath says.
Atlassian had to ensure that its organisational structure mapped to the microservices model and that each team had a manager, architect and mandate. There was a great deal of work to be done around expectation setting and ongoing communications with the teams. They hosted weekly meetings with presentations and demos every Friday, and ensured that they stopped to celebrate the successes along the way to make sure everyone knew that they appreciated the work.
"In addition, we had to make sure that our teams embraced the culture shift of transitioning to a ‘you build it, you run it' mentality. It takes time, but you need to give the team the opportunity to practice, to gather and share feedback, and have a ‘no blame' attitude when moving to this new way of working - that's what really made this move successful for us," he adds.
Like Viswanath, Hertz also emphasises the importance of culture in such a move, adding that microservices and their frequency of releases rely on highly collaborative and communicative teams. "If there was ever a time where teams have to work together toward one goal, adopting microservices makes that time now," she says. "It's actually a bit ironic that while containers and microservices are enabling this decoupling of application services, for the people, it's necessitating tightly integrated operations."
Fostering a culture that allows people to move as quickly as application architectures and technology will allow them is critical to success. For Hertz, this absolutely requires executive sponsorship to ensure that teams and people are doing what they do best—innovation, creative problem-solving—and automation and software is doing what it does best—routine tasks and processes. "The whole organization has to be work smarter to work faster," she says.
Keeping challenges visible
Michael Allen, VP and EMEA CTO at Dynatrace, cautions that the C-suite needs to consider whether this new architectural approach will create blind spots for IT teams. "The reality is that microservices are used in highly dynamic cloud environments, which often results in a lack of visibility for teams using legacy management tools," he says.
In fact, a Dynatrace survey showed that 56% of CIOs thought performance monitoring was a key challenge in managing microservices. The same survey showed 88% of organisations were using or plan to use microservices - so getting visibility into them and managing performance is something that cannot be ignored.
Mark Manning, Principal Security Consultant at NCC Group, says companies should not ignore the need to address security concerns during a microservices migration. He says it is vital that companies consider how the change affects the security of the application, whether the organisation has the right tools to support it, and ensure that staff has the necessary expertise to build and support the new architecture in the future.
"Our clients that are having the most success with microservices take advantage of its limited attack surface and will build controls around them," he says. "Before, your monolithic application may have opened multiple ports, saved files all over the disk, and made network connections to dozens of external hosts, but now your microservice might run on a single port, perform a single function, and only need to connect to one or two external systems."
In Manning's experience, the most successful implementations use network controls, permissions restrictions, Linux and Windows kernel isolation, and a slew of other security controls to harden a microservice and define exactly what it should and should not do.
Making the most of microservices means understanding the specific needs of the business and the application, while also ensuring that the right culture is in place to help teams really leverage the potential benefits and take ownership of a microservices deployment.