Executive Insights on Microservices

DZone 's Guide to

Executive Insights on Microservices

Learn what the most important elements of microservices are according to IT executives.

· Microservices Zone ·
Free Resource

This article is featured in the new DZone Guide to Microservices. Get your free copy for insightful articles, industry stats, and more!

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.

1. You can see how early it is in the adoption of microservices as the “most important elements” are all over the place with business processes, scalability, agility, APIs, decoupling, and management/culture all mentioned a couple of times.

Think about breaking down a business plan or process. Understand and define different business domains in an isolated manner. Understand the original monolithic process and what problems you’re trying to solve by decomposing the monolithic processes. It doesn’t matter that a single microservice is elegantly architected if the big-picture business processes aren’t executed successfully since these are what make the customers happy and make the company money.

Solve the real problem around engineering and scaling. Enforce an architecture that will help the organization scale quickly while being agile. Microservices allow you to pull off the inverse of Conway’s law. They should be independently developed, deployed, and scaled, allowing for faster delivery of functionality with little impact on other systems. Improve the ability to make changes and get them to the customer quickly. Think through the responsibility for each microservice and how they will interact with one another for greater agility and scale.

Isolation and API guarantees are key elements. Isolation enables developers to iterate quickly and independently. API compatibility is key so other microservices are not impacted or dependencies are created, which slow down iterations. You need well-defined APIs that can be easily discovered, understood, and executed by service clients.

Ensure microservices are adequately decoupled but avoid premature decomposition. Start small and evolve. Design applications to small teams can have full control of a service or an app that’s fully independent of everything else. If you are breaking down a monolithic application, take an iterative approach, decompose incrementally. Break out, run, and operate with a line of decomposition before you move on. Ensure autonomy for a service. Deploy independently at the finest level of granularity.

Microservices are a management issue moving from hundreds of developers working on an application to no more than 10 to12 people per team. The culture of the organization is critical as this is where we see the manifestation of communication problems. Without meeting the communication challenge, organizations don’t get the outcomes they want. Monitoring is a huge component of microservices with heavily decoupled distribution, service visibility becomes an issue quickly.

2. Microservices have made application development faster, it has given developers and engineers more autonomy, and it has increased the agility and scalability of applications.

Microservices enable everything to move faster – development, onboarding, feature release, adoption, uptake, feedback, and improvement. Things happen faster once you’ve broken things down. You get speed with quality because there’s a smaller surface to test.

It changes how organizations work and meet business requirements. Application developers get a lot of freedom. They get an API and can look at the end user, use, and release in a rapid way without dealing with backend complexity.

A team bigger than ten people is not efficient and hinders autonomy. It has given architects more independence and choice in selecting the technologies used by a specific microservice. They can select technologies that are the “best fit” for their specific microservice.

Microservices are beneficial to the agility and vitality of an organization. There is greater agility and alignment along a common, product-focused vision. Microservices force you to adopt an Agile methodology to be flexible and responsive because there are so many moving pieces. Testing is easier. Teams can be moved around, the learning curve is smaller, onboarding is quicker, small teams communicate more efficiently, and smaller code bases are easier to maintain.

3. Respondents are seeing rapid to moderate adoption of microservices and it seems to be driven by the adoption of mesh network management tools, such as Istio. Tools, systems, and platforms are making it easier, reducing the downside, and making applications more consumable. The transition to microservices-oriented networking has shifted thinking about sockets to microservices. The service mesh takes out the shared responsibility by putting everything in a container enabling everyone to use the same sidecar. Serverless computing also allows applications to be even smaller. The concept of a service mesh sprang from nothing last year and is continuing to generate a lot of interest and some adoption. However, these technologies are still in their infancy and adopters are discovering the hidden pitfalls. Patience is required as the industry sorts itself out.

4. The majority of real-world use cases provided by our respondents were in financial services, though several people pointed out the benefits of microservices are irrespective of domain. Everything being done in financial services can be used by a number of different verticals. The biggest and most relevant use case is fraud detection built out machine learning models and putting in line with microservices. A real challenge is agility around making an easy change to a process – like the credit-worthiness of a customer. Data scientists are able to make a change to a model quickly versus changing the entire software development lifecycle. Large financial institutions are able to deliver new functionality using microservices while maintaining and continuing to leverage legacy applications through API-based integrations. They’re able to provide new,all-digital products and services because they are better able to respond to customer needs without needs to rip and replace.

5. The most common issues affecting the creation and management of microservices are data, complexity, monitoring, skills, and security. A key challenge is managing data and data sets with stateful and stateless data. You need to understand how to create data compositions. You need to think about monitoring and observability with autonomous services disbursed across an entire network.

Most traditional organizations have to move legacy apps. That’s a multi-year journey. You cannot stop supporting the monolith. Simplicity is the most fundamental thing to keep in mind. Have clarity of the domain problem you are trying to solve. Create clean and simple APIs and logic that’s easy to wrap your head around to create more complex apps and behaviors. Microservices bring a lot of overhead. Microservices are more difficult to debug and troubleshoot.

There’s a pretty big skills gap when it comes to building, delivering and managing microservices. Few developers have the skills necessary to understand the domain, code the services from data to API, understand the overall architecture, integrate with a CI/CD pipeline, and deliver a running service. Most do not understand the gravity of building services as fine-grained and collectively using a single application.

6. The biggest concerns with the current state of microservices are observability and maturity. It’s really important to have visibility into business processes. How to know something is going wrong when it’s going wrong is key. The ability to do distributed training through the whole system is necessary. Without monitoring, you’re not able to see where the problem is. Istio helps with communication in a highly distributed network. Enhanced automation and operational visibility help shine light onto the increased complexity.

Microservices in production is more complex than we initially thought. We are confronting a lack of maturity in tools to monitor and troubleshoot. This delays the ability to move to production. Organizations adopting microservices need to know what they are trying to accomplish rather than a desire to be on the cutting edge. We need independent businesslogic but not technology choices. A lack of standards is resulting in confusion but as more organizations adopt, best practices and standards will fall into place.

7. The future of microservices is FaaS and serverless with improved tooling. Serverless is gaining traction too, and microservices are an important step on the learning journey that will lead us closer to serverless. The promise for the software developer of getting rid of operational detail is great, while the promise of huge cost savings by only paying for the exact amount of compute power used is even more appealing. FaaS is a few years behind microservices. Infrastructure will be less of a barrier to entry. Serverless and FaaS will enable developers to go smaller. Microservices are going to become even more micro with serverless. Serverless and FaaS are different but are the next generation of application development. There’s a lot of value in going to a serverless model.

There will be improvements in the development of Kubernetes and tools provided by AWS and GCS to help go from development to deployment and production more quickly and easily. Simplifying as much as possible so developers, operations, and DevOps can run the applications they want in a way that scales automatically, and everything is at their fingertips to troubleshoot any problems without worrying about the underlying infrastructure and orchestration.

8. When working on microservices, developers need to keep a lot in mind. Those items mentioned more than once are APIs, security, reducing complexity, and remembering SDLC principles. Every developer needs to have API development and management skills in their toolbox. Make service calls as autonomous as possible. Use APIs to minimize duplication of functionality across the organization. Concentrate on clean interfaces between modules.

Focus on secure design patterns. Endpoint security is crucial. Remove as much operational and design complexity as possible. Look for trends that hide complexity from developers and make them as productive as they can be withoutworrying about infrastructure. Dive into core SDLC principles. Understand the end-to-end lifecycle of a microservice to make yourself more valuable to employers and more marketable in the industry.

Here’s who we spoke to:

This article is featured in the new DZone Guide to Microservices. Get your free copy for insightful articles, industry stats, and more!

api, distributed systems, microservices, serverless, service mesh

Published at DZone with permission of Tom Smith . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}