How Microservices Have Changed Application Development

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, "How have microservices changed application development?" Here's what they told us:

Speed

• More than the codebase and breaking it up, it changed how we approach code development. New developers add value more quickly working on smaller code bases with logic you can wrap your head around. We develop features much more quickly. It's key in allowing developers from other disciplines to contribute to the codebase. It's more encapsulated and there's much less logic. If you encounter a problem, you can get up to speed and contribute code. Microservices is an enabler for the full-stack trend. It enables developers to contribute from end to end. It provides the ability of different teams in the organization to work in a decoupled manner on different services. It enables people to make progress independently without coupling. We see less use in object-oriented design patterns since microservices, by design, are simple. We don’t need extensive use of OOD since microservice is encapsulated small and simple.
• We experienced much faster development. New features get done faster. Before microservices, you had to align with six or seven teams. When you look at how companies build software today, smaller teams own the database and the infrastructure. Agile DevOps would not be successful without microservices. Small independent groups focused on specific features.
• Autonomy – a team bigger than ten people is not efficient. Microservices enable fast delivery to the market because the components are small. Speed to market results in faster adoption, faster uptake by users, and faster feedback which enables multiple releases per day or week — speed with greater quality because there’s smaller surface to test. You can put more attention on certain quality aspects. We've achieved speed, scalability, flexibility, and reusability with a higher order to share and reuse functionality within and beyond the boundary of our organization. This unleashes another field of technology innovation like IoT and web 3.0 paired with CI/CD and cloud. Microservices architecture better positions application development to survive, thrive, and adapt in the continuous economy.
• The adoption of microservices has allowed teams of developers to have much more autonomy in how application functionality is built and deployed, resulting in faster time to market. Instead of focusing on the rigidity and stability of monolithic applications, modern architectures need to be built to change. This enables adopters to address disruptive trends in their industries before they can have a negative effect on their business.

Freedom

• Whether using containers or functions, new technologies have allowed developers to bundle their applications’ dependencies with the applications themselves resulting in fewer run conflicts with libraries or languages. Each microservice can package its own set of dependencies, with greater freedom than in the past. Java is able to interact with Python microservices.
• You get rid of a lot of limitations of the monolith. You have the freedom to scale and deploy piecemeal. Focus on the services that you need to scale and be reliable. Backend state management opens up quite a bit. You can finish things and leave them alone. Once you finish something you leave it and move on, no maintenance overhead. Things happen faster once you’ve broken things down – that’s the loose coupling. Teams can be moved around, the learning curve is shorter, onboarding is quicker, small teams communicate more efficiently, small code bases are easier to maintain. It's clearly a better way to split things into more loosely coupled pieces.
• You can optimize the technology with containers and cloud-native features and have rapid releases with an iterative approach with a minimum viable product. Provide functionality quickly to the user, get feedback, and improve. It changes how organizations work and meet business requirements. Application developers get a lot of freedom. Application developers can get an API and can look at end-user use and release in a rapid way without dealing with backend complexity. Delivery of a feature down to creating a pull request and everything is streamlined with automatic integration, tested, and pushed into production. Reduces risk with canary deployment patterns. You can always roll back to the previous version.
• Every customer has monolithic applications. With microservices, individual engineers or DevOps team members don’t need to talk to anyone beyond their own teams and those on teams adjacent to them. That’s a huge win for communication, collaboration, and engineering management.
• It has allowed architects more independence and choice in selecting the technologies used by a specific microservice. They can select technologies that are “best fit” for their specific microservice, rather than making a technology work for their use case.

Agility

• Microservices make the organization more agile and vital. It's more of an organizational impact than technical engineering. More agile and aligned along with a common vision and more product focused. Testing is easier.
• Microservices have changed how we think about the entire SDLC. Microservices force you to adopt Agile to be flexible and responsive because there are so many moving pieces. It enables developers to let individual components go out when they are ready.
• It has made our developers more productive and allows them to be more innovative. If we weren’t using microservices, everything from development to testing would take us three times as long. We also see customer launch their solutions MUCH faster. If you’re trying to deploy a real enterprise website on Adobe or Sitecore, good luck getting results in under nine months. We enable customers to launch sites and apps – with huge quantities of varied content, operating at massive scale serving millions of eyeballs, featuring e-commerce and true 1:1 personalization – all of that, in a fraction of that time. It’s a startling reduction from months to weeks, sometimes even days. At the heart of this: microservices that allow the system to be built faster and in a more robust (yet flexible) manner.

Scale

• Microservices increase the speed of development and enable multiple small teams to work in parallel and test before integrating. We gained the ability to scale and build highly available fault-tolerant applications, and scalability.

Other

• When breaking applications into microservices, there is still a contract definition to be managed. The use of the microservice depends on how things have changed. If doing CI/CD, microservices is just another project. Make CI/CD more pervasive but people still struggle with contract definition interface management.
• Microservices break monolithic code into smaller pieces. When you want to write new code, take a microservices-first approach. Remember microservices principles like data isolation.
• From a business point of view, we’re in the risk mitigation space when someone is looking for a loan, they have a problem, they need money. They're not looking for products, they're looking for an amount of money to get them out of the situation. Monolithic applications were all about products. It's how we used to design software and product offerings. Microservices enable the design of customer-centric products and services. Get creditworthiness data from the customer and tailor make a product they’re looking for with a custom design and price.
• Microservices architecture and cloud technology have dovetailed with microservices architecture people to build and deploy applications on to cloud platforms. You have to build slightly differently. When writing my application, I’m leveraging a relational database which abstracts away a lot of nasty problems. Infrastructures can and do fail and the effect of breaking into smaller services we build for reliability expecting things to fail.
• Microservices have changed application development on a couple of dimensions: organizational and technical. Because microservices are designed to be developed and deployed independently, and each service focuses on just one business capability, we commonly see cross-functional teams made up of engineers, designers and product managers that are responsible for one or more microservices—teams are organized by business objectives. This is in contrast to teams that might have been organized by role or function in the past. This has its advantages. Organizing around business capability (instead of around role or function) makes it easier to add new teams to focus on new products and services, and overall scales a company’s product development very well. It also reduces friction whenever one service needs to be deployed and connected to the database. But the change in organization has introduced communication challenges that didn’t exist previously. Because a company’s core, revenue-generating business processes typically span multiple microservices, teams need to coordinate to ensure their services integrate in a way that makes it possible to fulfill these processes. The technical changes introduced by microservices are closely related. It can become more difficult to detect or troubleshoot issues inside a system that’s made up of many microservices. Simply getting visibility into cross-microservice event flows requires its own set of tooling and is not something that can be taken for granted. Organizations might see a wider range of databases and programming languages in use as teams have more autonomy and flexibility in making choices about what technologies to use to build their microservices. On the other hand, many organizations find it much easier to scale their applications because each service can be scaled up or down as necessary, and the independence of each service makes it easier to adjust single services to bring improvements to market and also to experiment with new features.
• There are two aspects here, the software side and the human side. For the first, the contracts and interfaces between services become more important: engineers need to define the proper boundaries between their services, and also think more about being forward and backward compatible with newer and older clients. For the human side, teams can now build, test, and deploy independently and that makes iteration much faster.

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