Microservices' Keys to Success

To understand the current and future state of microservices, we spoke to 25 IT executives from 21 organizations. Consistent with the early adoption of the technology, the answers to our questions were diverse. We asked respondents, "What are the most important elements of microservices?" Here's we they told us:

Business Process

• The Cloud Foundry application runtime PaaS was designed around microservices as adopted in larger organizations. Most of the material software being built are using the concepts of microservices. 12-factor applications are a series of design ideals with a benefit. It’s ideal for the way you think about breaking down a business plan or process. Adopters of our platform adopt the ideals of 12-factor application development and microservices but don’t go all in. Most have legacy code. Different apps and components fall across a spectrum from monolithic to FaaS. A single function to be applied on its own. The smaller application is the greater the benefit to having teams or individuals be responsible for the particular elements of a system with reduced coordination. The downside is that you end up with more applications, a lot of different apps to deploy and manage. There is a significant increase in complexity as a function of having many more apps. This is why application platforms exist – they mitigate the downside.  This is why cloud providers offer PaaS. Platforms make it easier to maintain and operate all of these applications along with self-healing and auto-scaling. You get the benefit of microservices with less operational downside. 
• [We need the] ability to understand and define different business domains in an isolated manner. Define a specific domain to a specific project. Understand how the system operates as a whole. Every service implemented and deployed separately allows you to choose the right tools for the job, [the] right framework, language, and stack. 
• Understand the original monolithic process, what problems you’re trying to solve by decomposing the monolithic processes. It can be difficult to get the paradigm shift of working with constituent parts. 
• It’s important to remember that a single microservice is almost always just one piece of a bigger picture. While it’s critical that an individual microservice is monitored and deployed in a responsible way, it’s also critical to keep an eye on the cross-microservice flows that make up most companies’ revenue-generating core business processes. It doesn’t matter so much that one single microservice is elegantly architected if the big-picture business processes aren’t executed successfully, as it’s these business processes that make customers happy and make a company money.  Said another way, it’s important to remember that microservices are a means to an end—a means to be more innovative, flexible and to react must faster on new requirements or feature requests.

Scale

• The movement is not new. The Unix philosophy is that all of the utilities are expected to do one thing and one thing well. Not more efficient message brokers. This philosophy is more of an approach to the software development discipline. Microservices provide the way to scale. Microservices allow you to pull off an inverse of Conway’s Law. It facilitates the next generation of Agile and DevOps. Enforce an architecture that will help the organization scale quickly while being agile. 
• The most important elements of a microservice itself are its level of granularity and its accessibility through APIs. Microservices should be independently developed, deployed, and scaled, allowing for faster delivery of functionality with little impact on other systems. As such, they should address a domain broadly enough to avoid challenges around “nanoservice” orchestration but bounded enough to avoid unnecessary dependencies. Once a microservice is deployed with the right functionality, it needs to be consumable by other services and applications – thus it needs to have a well-defined API that can be easily discovered, understood, and executed by the service clients. 
• Microservices offer compelling benefits: 1) Better Scalability: For SaaS and similar cloud offerings, it’s the ideal architecture, because you can address scalability issues by surgically upgrading the bottleneck, all without having to break the overall system or architecture. 2) Rapid Innovation: As stated above, no single vendor does it all and does it all best. Microservices allow you to unreservedly select and combine best-in-class providers and products. It also enables you to continuously iterate and adopt the latest and greatest technology as it evolves. This moves your solution forward at the speed of industry innovation, rather than being at the mercy of a single vendor and their roadmap. 3) Time-to-market: Perhaps unintuitive at first, but true nonetheless: If you start with a flexible, extensible, microservices-driven architecture, you will launch faster than if you try to deploy a big, monolithic behemoth of software. 4) Lower risk: The ability to pick and choose (and replace) components gives you more options and maneuverability, whether its eradicating bugs, ensuring up-to-date security or pivoting if a vendor negatively changes their pricing or terms of service.

Agility

• For us, we take a big app and slice and dice it into microservices thinking through the responsibility for each microservice and how they will interact with one another for greater agility and scale. We think about how the microservices will share data. Serverless is primarily for stateless applications. Keeping the data throughout the organization in sync regardless of the number of microservices. To do this you need to have a consistent view of the business – well-defined lines of communication and clarity about how to share data in real-life. We’ve written a blog post on data dichotomy. 
• [We need to be] determining when microservices are and are not appropriate. People see Netflix or Amazon that did SOA and built on the cloud with a nice story. Think they can do it and be successful. What are the problems Netflix and Amazon tried to solve and are you trying to solve the same problem? Greenfield projects “build as microservices.” Help understand what the problem is we’re trying to solve. Microservices is for having an app that evolved and devolved over time, a monolith that grew and grew. The architecture of the application became less defined and started to step on itself and became difficult to reason with and change. Too many people are working on the monolithic app. The process to build and test was prolonged. The application and architecture became a bottleneck to making changes to the system as quickly as possible. Architecting a system for scale requires knowing the scaling parameters you are building for. Caution teams to question that doing microservices is optimization for a particular problem that comes with a lot of complexity. Is that what you? Set out objective levels of measurement to determine if you’re getting value from this. If you can’t say that you are, then don’t do microservices for microservices sake – the goal is to improve the ability to make changes and get to customers quickly. Make sure you have room for a co-located application. No one solution is right for everything.

APIs

• Customers in Silicon Valley are moving to microservices at a slow and steady pace. People outside of Silicon Valley are dabbling in microservices. Start-ups are doing microservices from the “get-go.” We help from a static analysis perspective. Microservices code has 5X the vulnerabilities of monolithic code. Microservices are interface based, there is no governance behind the scenes. Developers take comfort in their ability to rewrite microservices. When writing microservices many assumptions are made around how they are used and consumed that does not hold true. On the flipside, the rate of remediation is 2 to 3X better than monolithic code. It's easier to do. We have a product to statically analyze microservices code. Surface as APIs to perform continuous API testing. 
• Isolation and API guarantees are the most important elements of microservices. Isolation allows developers to iterate quickly and independently. However, developers must maintain API compatibility so other microservices are not impacted (and create dependencies that slow down iterations).

Decoupling

• Not all services are microservices. Make sure they are adequately decoupled. If tightly coupled can’t scale a component. People have difficulty understanding where ingress and egress points give way to microservices. Need to understand the clean lines like common-sense load balancing. 
• It depends on what you are trying to do. Greenfield apps are much better than chipping away at the monolith. Avoid premature decomposition. Don’t start with 65 services. Start small and evolve. If you have a huge domain understanding, then you know enough to layout the composition of the services in some detail. Be conservative in your approach. When evolving existing apps, understand where you are today and what you are trying to achieve. The easy part is breaking the code and fixing dependencies to build services independently of each other. The hard part is breaking the data dependencies of state apart. Splitting the data becomes the hard part. Caching can become more difficult. Data dependencies shared between services can cache easily. Be conservative when starting with greenfield and evolve as you add functionality. 
• It depends. Design apps so small teams can have full control of service or app which is fully independent of everything else. Make them truly independent from the rest of the application. If breaking down monolith into microservices take an iterative approach. Decompose incrementally. Break out, run, and operate with a line of decomposition before you move on. Even when you are designing from the ground up, don’t be overly zealous for decomposing the application just for the heck of it. Ensure autonomy for a service, assign to one team, deploy independently at the finest level of granularity. A common mistake is that people don’t understand the boundaries of what a service should be (e.g., service for data access layer). Define as a set of business functions not as a technology. Lack of understanding around microservices and properly defining boundaries. Microservices in name only approach. Design-driven design.

Culture

• It depends on where they are in the process. If the organization is young enough, it started with the pattern in microservices and people are on the leading edge. Most of the market has a significant investment in monolithic applications. Microservices is a management issue. Hundreds of developers working on an application. To be successful, you have to work within team boundaries of no more than 10 to 12 people per team. Solving a real problem around engineering philosophy and scaling.  How they do it, think about microservices as the services look like an ant farm rather than a commune. Need uniformity in how they are built. Common orchestration framework, how to build for security and monitoring. Need to manage expense as services grow to the hundreds or thousands. 
• The culture of the organization is one of the most important. It's the manifestation of communication problems. Without meeting that challenge first, organizations don’t get the outcomes they want. Monitoring is a huge component of microservices with heavily decoupled distribution service visibility becoming an issue quickly. 
• As you change the architecture of your applications, you will need to modify how you organize your teams so that they are aligned. Further, operations become a critical piece of the equation as we introduce automation of the software supply chain with these services.

Other

• Form factor. People used to think containers were the only delivery vehicle. That’s changing with FaaS and serverless. You don’t need containers to implement microservices. A new set of frameworks allow you to use source code directly as a unit of application.  Once you’ve chosen a form factor you need to consider the orchestration layer. In a container world, everything is consolidated to Kubernetes (K8s). With the emergence of FaaS and serverless containers and K8s are not necessarily the answer. FaaS can bypass the complexity of containers. Once you’ve made decisions around form factor and orchestration the next set of decisions depend on the stack. What’s the best way to configure the application? A lot of tools and community projects and opinions – a templating engine, configuration maps, we developed our own. The next thing to consider is the triggering mechanisms. Typically microservices will execute in response to some event. A user will think about if microservices should be activated with REST API call or HTTPs. Depending on the type of event it may determine additional tooling is needed for microservices. Other things to consider – logging, how will logs, produced by microservices, be collected, aggregated, how will ops teams troubleshoot microservices when they don’t behave as expected? There is an entire industry of tools and best practices. The same for performance monitoring which has changed quite a bit with the Prometheus tool emerging as the preferred way of aggregating and ingesting data and making it available for queries. It helps developers troubleshoot performance problems.
• Ballerina is a language we introduced for centralized integration services. The second thing is properly using containers or else you will not realize all of the benefits. We provide support for containerized environments. A microgateway for API management and integration. We identified the concept of service mesh. Integration and composition were not addressed by most microservices frameworks. We identified the importance of integration, migration, and inter-service communication. Ballerina supports out of the box – GraphQL. We encapsulate as part of the language and framework, so developers can focus more on the business logic and less on the communication elements. Offloads inter-service communication to a separate site call co-located with your service. This is becoming more common with Istio. We are able to deal with different compositions and frameworks. We believe in microservices and the entire microservices architecture. We identified microservices as too granular. We developed sales-based architecture. How you can group a set of microservices and expose via a gateway. Local data is managed locally. This is the service mesh concept. Two layers the control plane and the data plane. Local control plane and local data plane is a public shard to address brownfield legacy data and greenfield data. Cloud native sales and legacy sales. Wrap legacy with ESB. External sales working with partners and using Salesforce and Workday. A lot of application development that is done have application sales at the top of the architecture. Any runtime we see in the enterprise is a component. Definition of a service is the aggregation of components. People are going back to microservices and putting them into a single plane. This does not optimize the process. You need to have an organized team to plan, develop, and run microservices. We evangelize the microservices concept by hosting workshops.
• To us, the key elements are modularity and replaceability. People often put a huge amount of emphasis on code-reuse but being able to replace a legacy service with a new one is a great benefit of microservices.

Here’s who we spoke to:

• Heikki Nousiainen, CTO, Aiven.io
• Chase Aucoin, Technical Evangelist, AppDynamics
• Assaf Mizrachi, Head of Software and Amit Ziv-Kenet, Backend Developer, Augury
• Bernd Ruecker, Co-founder and Developer Advocate, Camunda
• Jaime Ryan, Senior Director, Product Management and Strategy, CA Technologies
• Brian Dawson, DevOps Evangelist and Viktor Farcic, Senior Consultant, CloudBees
• Chip Childers, CTO, Cloud Foundry
• Gwen Shapira, Chief Data Architect, Confluent
• Matthew Baier, COO, Contentstack
• Anders Wallgren, CTO, Electric Cloud
• Priyanka Sharma, Director of Alliances and Andrew Newdigate, Infrastructure Architect, GitLab
• Ben Sigelman, CEO, LightStep
• Jim Scott, Director, Enterprise Strategy & Architecture, MapR
• Ariff Kassam, Vice President, Products, NuoDB
• Jim Walker, VP of Product Marketing, OverOps
• Bich Le, Chief Architect, Platform9
• Mike LaFleur, Global Head of Solution Architecture, Provenir
• Christian Posta, Chief Architect, Cloud Application Development, Red Hat
• Setu Kulkarni, V.P. Strategy and Business Development, Whitehat Security
• Asanka Abeysinghe, V.P. of Architecture – CTO Office and Kasun Indrasiri, Director, Integration Architecture, WSO2
• Roman Shaposhnik, Co-founder, Zededa