What Devs Need to Know About Microservices

DZone 's Guide to

What Devs Need to Know About Microservices

Developers need a good knowledge of APIs, secure design patterns, how to reduce complexity, and the fundamentals of the SDLC to work with microservices.

· Microservices Zone ·
Free Resource

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 them, "What do developers need to keep in mind when working on microservices?" Here's what they told us:


  • Keep the Kafka API, learn it. Know when to deploy within Kubernetes (K8s) for orchestration – whether you're running 10, or 100, or 1,000 microservices you need orchestration. Broader adoption and understanding of frameworks list ISTIO will help push everything forward.
  • 1) Embrace the distributed nature of the applications in microservices architecture. If you make yourself comfortable with that then become comfortable with K8s and cloud foundry. 2) Test and verify changes. Use different approaches of how you construct end-to-end testing. 3) Become comfortable disclosing internal states of the component responsible for via well-structured APIs. Now all components are a service with APIs around it. Every developer needs to have API development and management in their toolbox.
  • Picking the right tool, the right programming language, and the right framework to develop your services, based on your requirements, is critical. If there’s going to be a lot of database interaction, you will need a particular technology. Determine what kind of calls to use, then make your technology selection. Architecture is all about using multiple technologies. Pick the right tool and language. Micro is not the size it’s about the scope of the service. Provide a better experience for the end user -- focus on UX. Make service calls as autonomous as possible. Use APIs to minimize duplication of functionality across the organization.

Secure Design Patterns

  • Focus on secure design patterns. Be aware that your microservice is more powerful than ever before. It may be sitting on the front page of a bank's website helping people log-in or make transactions. You need governance controls for development and deployment put in place by your security teams. Make sure rogue microservices don’t make it to production. Model threats early in the SDLC.

Reduce Complexity

  • Make sure the platform, the cloud provider, and the language frameworks selected remove as much operational and design complexity as possible. Then refocus on thinking about the business process you are trying to enable. You cannot do both at the same time.
  • Before you start, do a careful assessment to determine if you in the right place, do you have the right knowledge, experience, team. We believe in a POC approach. Don’t jump in until you’ve done a prototype on a small scale. Think simple and small and let the system evolve in an organic way. Ongoing processes are always evolving and learning testing new features – it's a long-term process.
  • Don’t believe the hype. Go to conferences to understand where the trends are. If a technology seems unnecessarily complex don’t assume you have to learn it. There are new tools and new ways of thinking that are emerging all the time to make developers' lives easier. Serverless. Look for trends that aim to hide complexity from developers and make them as productive as they can be without worrying about infrastructure.
  • Microservices are not a magic panacea and more is not necessarily better. They bring a lot of complexity you may not expect if you’ve spent all your time in the monolith world. There’s a lot of issues with services and it took us a year to break them out. The first stab is straightforward and then you discover tendons that still connect pieces and you slowly and painstakingly fix them. It is possible that not adding more services will work for us for a while. Greenfield is different, of course.


  • Dive into core SDLC principles. Have the ability to interact and give value to the business is critical to your success moving forward. Be able to communicate value your work is producing.


  • Tools keep changing but the core architectural ideas are still useful today. Make sure you have good experience with domain-driven design, event-driven design, a solid grasp of architectural concepts before looking at serverless, K8s, and service mesh. Keep your eyes on the goals of microservices.
  • It depends on what you are going to do. If you are going to be the engineer, have good system comprehension. Architectures that force good system comprehension are good things. If you take a team that doesn’t know the application well and tease it apart, you’ll have a mess. Understand individual service testing and testability. Don’t get pigeonholed into particular toolchains be open and flexible understand strengths and weaknesses of the various platforms and pick the best one for what you are trying to accomplish as you get up in the leadership and architecture.
  • 1) If an organization doesn’t have a short list of standards start the initiative. 2) Think about managing code in addition to writing and the total cost of ownership. Think hard about how to discover and remediate issues.
  • Concentrate on the clean interfaces between modules. Consider versioning between interfaces. Stateful/stateless is an important consideration. The more you can do stateless the easier it is.
  • People delegate security and that sort of thing to other systems so endpoint security is crucial.
  • A major change is that this new world of developers has to know everything up to a certain level. High-level knowledge of the lifecycle of an application and then the details of your specialty. You need to know deployment. Increase in specialization. Understand everything and then specialize. You can’t hide by not knowing something. Great interdependencies with specialty. Understand the tools and technologies that may have been the domain of another team. Understand new processes and proactive with CI/CD. To optimally shift to a microservices architecture requires a cultural shift as you decompose into two-people teams we shift to cross-functional team with dev, QA, and operations. If people are making the shift to CI/CD, containers, and container orchestration, microservices can be overwhelming. There is a significant learning curve. Look at emerging solutions to flatten the learning curve. Tools are a result of the implementation of certain processes born out of a certain culture. You cannot have siloed applications and expect microservices will ever work.
  • Stateful microservices introduce additional complexities that must be considered when architecting microservices. Specifically, architects will need to consider business transaction boundaries across multiple microservices. In addition to supporting atomic transactions across multiple microservices, architects also need to consider backup and restore strategies for those business transactions. When business transactions span multiple microservices, the data for those microservices cannot be backed up independently since they comprise a single business transaction. As a result, architects will need to consider creating microservices also business transaction boundaries.
  • In general, continue to learn. Embrace learning. Successful developers continue to learn. Learn but be skeptical, why are we doing this? What is the value to be gained? What can we do to validate the value we’re going to get?
  • Though microservices provide developers with more autonomy, with great power comes great responsibility. Developers should be aware of the enterprise context and the ecosystem in which their services will be deployed and consumed. Those who understand the end-to-end lifecycle of a microservice will be more valuable to their employers, and more marketable in the industry.
  • Failure is inevitable when working with distributed systems (e.g. fallacies of distributed computing, and so it’s important to design applications to be resilient. This is relevant both when isolating failures to prevent one service from bringing down an entire application (for example, implementing a “fail fast” pattern using a circuit breaker or similar tool) as well as taking responsibility for failure rather than passing the responsibility back to upstream services or in the worst case even the end user. Is your application designed, for example, to perform a stateful retry when a certain service was unavailable? How do you ensure every “long-running flow” that spans multiple microservices always finishes once it starts, even if something goes wrong (or if it can’t finish, that you notify the right person to look into the problem)? To be fair, there are times when pushing the responsibility of a failure to the client might make business sense—the important distinction is that this decision should always be made intentionally, and not just because state management and retry logic are difficult to implement.
  • Finally, developers have to ask themselves, what is an “application”? The borders are no longer clear, so you must think through internal governance and resource utilization. Ultimately, you become more aligned with the outcome which is the business value and less aligned with the “application.” Beyond the baseline stuff, developers need to be aware that troubleshooting distributed systems is complicated. The scope of a problem is no longer contained within a binary – it may involve hundreds of components. Understanding the complexity of multiple services running and knowing how to identify where troubles occur in a particular instance of a service is also troublesome. Log files will no longer cut it. Simple log aggregators will not solve the problem either. You have to monitor your logic in new ways.

Here’s who we spoke to:

microservices ,enterprise ,software architecture ,api ,design patterns ,sdlc

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}