What Do Developers Need to Know About Microservices?
What Do Developers Need to Know About Microservices?
When getting started with microservices development, you should be sure to start with the twelve-factor application methodology.
Join the DZone community and get the full member experience.Join For Free
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 do developers need to keep in mind when working on microservices?" The answers were wide-ranging. Here's what they told us:
Twelve-Factor Application Methodology
- Learn automation, logging, and tracing. Transaction IDs will thread through your logs. Have proper preambles, time stamps, execution context from microservice to microservice always in the thread of local context.
- Have security thinking in place. APIs use restful web services. Have a common contract language. Have API thinking in place. Have a cultural mindset to be more collaborative. Always have a process in place. Identify the right architecture for everything. Work together for the end customer.
- A Strong strategy for identity and security layer. Get the core pieces right.
Keep It Micro
- Keep it micro. Focus on how it manifests to the user. Think about security from the beginning.
- Many junior developers see microservices as a magic bullet and talk as if it will solve all their problems. Well, it also introduces a fair amount of problems of integrating with persistent storage. The temptation in the tech industry is to treat technological improvements as a cure-all. I saw the same thing a decade ago when "cloud computing" was all the buzz only to find out that it usually swaps out intermittent failure problems with latency and noisy-neighbor headaches. There's always a tradeoff. Containers aren't the best design decision in every use-case.
- Never stop learning. The velocity of change you see today is as slow as it will ever be. Test drive new languages, try new containerization technologies, and acquire a fluent understanding of the practical design challenges facing new architectural implementations today. Those challenge areas are where emergent solutions will appear, produced by industry or open source development. That’s the ball to keep your eye on. Whether it’s orchestration, secure containerization, remote configuration management, process mining, or something completely new, you must never look at a new concept and believe it to be off-limits to your ongoing education.
- You shall use standard or self-explanatory names for message properties. You shall use known libraries. You shall do one thing and do it well. And, please, check for null values. Jump in using JSON and keep looking for opportunities to use.
- Go beyond the boundaries of thinking of applications as a single system. Understand distributed computing. Let microservices dictate the data model – everything won’t be relational, there will be geospatial, unstructured, and classical translations. Understand the spectrum of data management. Domain-driven design. Eliminate the risks and pain points.
- Know Kubernetes and the complexities. Pods, the relationship between pods and clusters. Understand how to think outside the technology when building technology. This also makes it easier to learn new technologies. Learn new languages more quickly. Understand the business problem and how you can use technology to solve it. Be skeptical of something getting in the way – this is supposed to be easier. Do recognize the need to be a good citizen as you are part of a large, complex organization.
- Without a solid underlying communications architecture, the distributed nature of the system is complex - more complex than a traditional monolithic architecture.
- Don’t get locked into a single solution. Being too big can slow you down. Being too small can result in unnecessary interdependencies. Don’t get hung up on size. Be willing to split or combine. Be prepared to refactor as needed. Have a strategy for converting monolithic applications to microservices. Look at what others have done. There’s no need to create a completely new methodology.
- When working on microservices, developers must be simple and discrete. A service should not be complicated. It should solve one singular problem. It should be as simple as: Give me seven data points and I will give you a score. Nothing more.
- There are a lot of libraries out there for developers to reference. Use small single libraries. Retry connections. Own your own data. Data should reside where the business resides. Build in circuit breakers. Monitoring. Take a look at Go Standard, HTTP routing, and circuit breaker libraries right off the shelf.
- Better understand CD and its components. Automated testing, collaborative development, continuous testing, lightweight interface design. Change the approach to databases and database design. Think about how to manage the synchronization of data.
What do you think developers need to know about microservices?
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
Opinions expressed by DZone contributors are their own.