To gather insights on the state of microservices today, we spoke with 19 executives who are familiar with the current state of microservices architecture. We asked them, "What are the most important elements of microservices?" Here's what they told us:
- Overwhelmingly the benefit for our customers is speed. The microservice architecture plans we develop for our customers emphasize the speed of new feature development, of ongoing maintenance, and of the day-to-day work of deployment and testing. Frequently our customers are fighting against the relative slowness of their own processes at IT, such as change request management and testing. These processes tend to be stable and reliable but highly inefficient, which stifles the nimbleness and market responsiveness that executives desire.
- Faster development and iteration. Easier to maintain and refactor. Easier to control. Fewer dependencies across teams (we run five), automated test suites, less coordination required, an approach (all well documented with good client libraries), governance groups with different leads from different teams.
- Scalability is critical. Think about how to structure to scale in multiple dimensions and run on multiple machines. Low coupling and high cohesion between the parts.
- Easily scalable and deployable.
- The ability to keep things as generic as possible: every microservice should do only one thing, no matter the message source context, no matter what is next. Splitting big tasks like that is much more maintainable and programming business logics is a lot easier.
- Provide the ability to decouple and deliver application functionality faster with greater stability, agile development and teams to downstream delivery of applications with the ability to recognize the potential around agile and DevOps. Microservices and DevOps go hand-in-hand. There’s a reciprocal relationship. To deliver microservices as a core part of your architecture you need the component production of DevOps – agile, CI, CD. Decoupled apps are difficult to deliver without DevOps. Reverse relationship to implement DevOps to deliver faster you need to decouple apps into smaller elements.
- Culture. Evangelists have done a good job of explaining the benefits of microservices. Smaller teams with easier challenges to be overcome. Cultural shift is a learned experience to a more distributed network. Change in mindset and processes. Good communications to ensure everything is working together. Team enforces security. Big chunk in DevOps and adopting DevOps is important to ensure developers and operations communicate in an agile and collaborative way. Make sure to update the test cycle, communicate that you are doing do and how to iterate.
- Change the security model. From a single session with a monolithic application to API sessions. Build for agility, alignment to problems and teams. Digital transformation. Strong need for a customer identity platform.
- Portability is the greatest advantage. We get the same practical benefits of a Virtual Machine, but the transfer size is usually between 0.02GB and 2GB. A VM starts at 2GB and will often exceed 20GB. Because they are 1/100th the size to move around, it makes it practical to transfer over even spotty internet connections and we can do it while working with a client rather than as an overnight download. This speeds up development time when on-site and improves our customer's perception of us. After portability, consistency is a big benefit. Containers are most popularly used in a Linux environment, and the problem with Linux is that every distribution is different. These differences need to be accounted for when you're doing security auditing and compiling new software. If you use a container, then you bring that development environment with you. It also makes it much easier to address CVEs (common vulnerabilities and exploits) because you can fix it on your development environment, type in two commands, and then that security patch is available to everyone.
- It is our strongly held belief that microservices would benefit the most by having their own autonomous, local data source. Not only does it make microservices perform faster, it gives them proper scoping so that they’re not doing too much ‘behind the scenes’ thereby keeping them simple and easy to use. This is especially true when you take into consideration the fact that you can build microservices to use a replica of a master data source, the way it’s available in Oracle Berkeley DB and NoSQL database, not to mention Figaro. Why strain your network with queries when you can have your entire data source available within your runtime?
- There are three basic elements of microservices that are crucial: 1) Microservices are agile. Let me paint this as a story. As a Chief Risk Officer, I have my team expose a scorecard as a service to be used as part of the credit underwriting process. The Chief Operations Officer is in charge of that process. As part of the exposure of the scorecard, we agree that if the underwriting process passes seven variables to the scorecard service, the service will return as a score. As long as I don’t violate the contract - give me seven data points, and I’ll return a score - it doesn’t matter to the underwriting process how the score is calculating. This means, if the risk team discovers new data sources they can leverage, or if a new scoring model is created, they are free to implement it; that change will not negatively impact the underwriting process. This level of agility means risk professionals can quickly adapt to a changing risk landscape. 2) Microservices are resilient. In the example above, as long as the service that is exposed adheres to the original contract, the processes that rely on the service will not break. Both sides of the contract - give me seven variables and I will give you a score - are able to best meet terms in the contract. The underwriting process can retrieve the variables any way deemed best, and the scorecard service can calculate the score as deemed best. As long as the contract is adhered to, neither is impacted. 3) Microservices are open. At this point, most microservices are designed to leverage REST as the mechanism for data exchange. REST is showing itself to be secure, lightweight, and flexible. This open nature represents huge potential in building end-to-end processes that best meet the operational needs of the enterprise.
- There are different variations of microservices. What we are noticing is when people think about a microservice architecture, they often think all your microservices will be a single type that is business logic heavy requiring custom code. With some of our web-scale customers we see that, however, this is not the only type. In fact, most enterprises will have integration logic heavy microservices. They have to connect to SaaS applications and legacy back-end systems. There is a need for these connectivity microservices. We expect there will continue to be a mix of these.
What are the most important elements on microservices from your perspective?
Here’s who we spoke to:
- Thomas Butt, CTO, CardCash
- Matt McLarty, Vice President, API Academy, CA Technologies
- Brian Dawson, DevOps Evangelist, CloudBees
- Lucas Vogel, Founder, Endpoint Systems
- Ali Hodroj, V.P. Products and Strategy, GigaSpaces
- Job van der Voort, VP Product, GitLab
- Kevin Sutter, MicroProfile and Java EE Architect, IBM
- Sandeep Singh Kohli, Director of Marketing, MuleSoft
- Karl McGuinness, Senior Director of Identity, Okta
- Ross Smith, Chief Architect, PITSS America
- Mike LaFleur, Director of Solution Architecture, Provenir
- Gianni Fiore, CTO, Rebrandly
- Peter Yared, CTO, Sapho
- Sha Ma, V.P. Software Engineering, SendGrid
- Keshav Vasudevan, Product Marketing Manager, Swagger/SwaggerHub, SmartBear
- Chris McFadden, V.P. Engineering and Operations, SparkPost
- Christian Beedgen, Co-founder and CTO, Sumo Logic
- Todd Millecam, CEO, SWYM Systems, Inc.
- Tim Jarret, Senior Director of Product Marketing, Veracode