How Well Designed Is Your Microservice?

Microservices are not what a lot of people think they are, so what are microservices? There are some defining characteristics of microservices that liberate the approach, but which also add some serious challenges to their adoption and use. Designing microservices is not a simple task: when you adopt a microservice architecture, you buy into the challenge of creating independently deployable services. You don’t get to test these things together before release, and if you do test them together first, it isn’t by definition a Microservices approach. This makes them a complex choice.
In this episode Dave Farley, author of the best-selling books Continuous Delivery and Modern Software Engineering, describes what it takes to design and test a variable microservice, and explores the use of contract testing, and loose-coupled interface design, to retain their deployment independence.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 Building Microservices: Designing Fine-Grained Systems, by Sam Newman ➡️ amzn.to/31PyXOS
📖 Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, by Sam Newman ➡️ amzn.to/35IB8EO
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ oc.to/Dave-Farley
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com

[@m13v2]

“bounded context” as per ddd, that’s a namespace in which every word has a distinct meaning. that is much larger than what people usually use as the scope of a microservice. (i even met people who believe that an “aggregate” refers to the resulting state in event sourcing. or that the last part of the ddd book is the important one. either because it has these fancy patterns or they are tasked with splitting the company into verticals.)

[@brownhorsesoftware3605]

Working on microservices sounds a lot like working on platform software. But I have an address-related story from when I started my second job at a bank services shop.. It was 1980, ATMs had just become legal in Chicago, and my first assignment was to generate an input tape for an outside firm to print address labels. I was given a format to generate with separate fields for number, street name, direction, town, etc. I had to write a parser to produce this from free form 2 line addresses. It was a nightmare. Everyone started panicking because the labels were unusable. So, while I wrote a little label generator for the free form input, the ops manager went out and got some labels. Less than hour later, voila - here are your labels. They had never bothered to ask if we could just print the labels ourselves.

[@MisFakapek]

And again. Dave why you are always covering topics that are affecting my organization at the same week! Are you spying on us?

[@shau4744]

I was about to say the same. Addresses can be quite annoying ;)

[@judgemental_coder]

looks like everyone is in the same page

[@ContinuousDelivery]

🕵🏻‍♂️😂

[@delberthjulensbeti515]

Thank you Dave!

[@ForgottenKnight1]

Sometimes a service interface changes because the business changes and the new modifications might be breaking changes for consumers. The solution I found in this case is to keep both versions, but mark one as Obsolete (I am working mostly with C#/.NET). There are also many other ways to notiy your users that you are going to decomission this functionality in the near future, so they should start making changes to adapt to the new version.

[@rcrawford42]

My employer has taken a different approach -- integration test everything in stage, and now problems in staging are considered as critical as production issues. We have to drop everything when something goes wrong during testing, support twice as many environments, and can't dig into our issues because if we leave a problem in staging too long we block other teams!

[@ContinuousDelivery]

It is a good strategy in general, and a bad strategy of microservices. Testing everything together, works fine as long as it i part of a CI process, and delivers fast, in minutes, feedback. If it is slower than that, stuff is broken all the time.

[@m13v2]

yeah. the rules of the game change when you go faster. 1) when you get notified about the failure in staging within a few minutes, then you won’t need to drop everything because you’re most likely still holding it. 2) blocking: if you have a clean code base were people new to the code can understand it within a few minutes, a blocked team has a chance to resolve that on their own. 3) small commits continuously deployed to trunk: you don’t have to look much for where the error might be 4) coupling: some people design their microservices to be highly decoupled so it doesn’t hurt much when something goes wrong. start/stop a service to enable/disable a feature in the system. each service has all the data it needs in it’s own database, which is filled from the data warehouse if needed when the service is deployed. etc.

[@shaneagibson]

@@ContinuousDelivery It also raises the issue of how you keep the integration tests up-to-date, when the underlying functionality is evolving independently by various teams.

[@ContinuousDelivery]

@@shaneagibson For microservices, there aren't integration tests outside of an independently releasable unit. Contract tests, as I described, can be used to notify you of breaking changes, but inter-service testing doesn't scale well.

[@shaneagibson]

@@ContinuousDelivery Completely agree! It's no different than changing the internal implementation of a well tested method. You don't need to retest how and where that method is used - it's superfluous.

[@ugandandev]

I have definitely subscribed !. The name of the channel alone was alone enough for me to subscribe

[@ContinuousDelivery]

Thank you!

[@osisdie]

Sometimes customers still prefer to use old APIs so V1 API support might last for years, then seems to develop V2 API could be totally irrelevant to V1, even to generate a new endpoint is safe at all. However, that's from customer's point of view. Microservice internally resides many services coupled together on not only contract but also API Urls, then in this situation, I agree with Dave that do more contract testing on both of V1/V2 data to see if you are doing a backward compatible design but better also test endpoints because that would be another contract for external/internal systems.

[@ilovepickles7427]

Thank you again for the wonderful lesson. Every time I watch one of your videos my programming IQ goes up.

[@ContinuousDelivery]

Glad to help!

[@simonk1844]

Thanks for another great video - the points about the primary purpose of microservices are spot on. I was a little concerned about the brief suggestion of using "classes" to decode the data emitted from an API. This sounds to me like suggesting that a microservice should produce a matching library to use its API through - but that pattern has some serious consequences. As pointed out later, a true microservice cannot impose changes on its users - including forcing them to upgrade to a newer library version. A library which has dependencies can also be unpleasant. And finally, a library forces a specific language choice on its users. So this service-isolation-via-library pattern is one I'm very careful about. It's also one reason why I dislike Microsoft platforms; they often use the library pattern - eg much of the Azure cloud has very poor raw APIs that are made usable via library wrappers - which is a problem when using less-supported languages such as Python (I'm talking from experience here!). And regarding API backwards compatibility, I can recommend AVRO and Protocol-buffers. AVRO is widely used with Kafka, but can be used independently. Protocol Buffers is the default encoding for gRPC, but can also be used independently. Both are much faster and more compact than XML or JSON, and both are extensible, ie can be changed in limited ways without breaking existing readers and writers of older formats. For both these formats, there are also tools to detect backwards-incompatible changes at build-time or deploy-time.

[@giovannicuccu72]

If I undestrand correctly you say that when looking at the transport(and serialization?) performances json,xml,etc are not so good standards for exchanging data. Can you list some alternatives (that preserve some of the good sides of the textual standards)? Thanks a lot

[@ContinuousDelivery]

There are Protocol Buffers from Google (developers.google.com/protocol-buffers) and something called SBE (Simple Binary Encoding - www.fixtrading.org/standards/sbe-online/) I have also seen, and done, in-house versions that worked well. I have something that I wrote for use in for my own projects.

[@xybersurfer]

do you have any opinion on GraphQL, that promises to allow clients to retrieve exactly what they want? i haven't looked at it very in depth myself but it seems like a really concept although the implementation seems to fall a bit short (my first impression). i think the concept is interesting because it wants to get rid of predicting a client's most likely access patterns, like you mention here. firing something like an SQL query at a service is a scary but interesting concept of removing indirectness

[@Thorax232]

Simplest defintion of GraphQL: Functions as nodes on a graph. They are related by mapping outputs to inputs. What you do with that is up to you. And it's a very powerful idea. It's why it makes such a great microservice gateway. With schema first design (which I recommend) you explicitly define the shape of your data and the relationships between the data, then after add the logic to fetch that data. The poor implementations of GraphQL are GQL as a service providers like Hasura, or generators that just introspect a database and turn it into a "graphql api". This is a bit pointless. And doesn't take any advantage of what the spec provides.

[@macigli]

I don't know that I need CD or microservices or agile... what I need is a list of tshirts that Dave has in his wardrobe. :)

[@ContinuousDelivery]

I don't have a list of the ones that I have, but because people liked my shirts so much, we did a deal with the company that I get mine from, if you use this link you can get 10% off 😁😎👕 www.qwertee.com/?

[@mateussarmento7692]

This looks so much like David Parnas papers. Microservices are like the embodiment of principles of modularity and information hidding.

[@ContinuousDelivery]

I take that as a compliment, but also agree that there are foundational principles at play here. You don't get to duck the importance and value of these ideas. If you ignore them, they will come back to bite you. If you add them to your tool-kit, you will build better software.

[@caractacustube]

So many different concerns dumped on the term "microservices". Just like religious discussions, microservices discussions go nowhere because everyone us having their own micro-concersation. A bounded context is necessary to discuss aspects of microservices.

[@unixbashscript9586]

Microservices are meant to be decoupled from others. But can you really ever achieve this? Imagine you are developing something that requires websocket connection, now another one of your services will need to be updated in order to understand wss. Isn't this coupling thing together again, or am I wrong about it? How would you really develop microservices independently? Edit: I sometimes tend to comment before watching the entire thing lol

[@jayshah5695]

One more approach is to test complete systems in production behind feature flags. But it is a tech debt to be cleared out later

[@ContinuousDelivery]

Yes, I talk about testing in production here: kzbin.info/www/bejne/hJ7YZYiIdpyjia8

[@davethorn9423]

Contract testing ... Use Pact

[@oddassembler]

You have excellent thumbnails

[@ContinuousDelivery]

Thanks, my son, Tom, does the thumbnails, he's very good.

[@yapdog]

It sounds like you're describing data models versus event models. In a data model, only blobs of data are returned from microservices; no actual operations are performed. IMHO, data models aren't microservice architectures; they are databases. Having said that, my system utilizes both with no distinction enforced between the services. Time will tell if my bet is right, but so far, so good....

[@ContinuousDelivery]

Not really. The difference is the degree to which the producer and consumer of messages are coupled through their understanding of the message content. If my service is delivering, I don't know, video-streamed content. Then I may not care about the actual video content, but the codec that translates it does. So my service may be ignorant of the nature of the content, your service that receives the video may be ignorant of the content, but at some point the thing that shows the video can't be. Where the "understanding of the content" takes place matters a lot, the nature of the content, not so much except to understand where "understanding" takes place. Loose coupling is a way to defer, or manage the limits, of understanding. Tight coupling, like with a CODEC requires standards that don't change. None of this changes whether you are thinking about serving "data" or "events".

[@Gauss6174]

unfortunately at the moment, i'm too stupid to understand everything he's saying since i've no development experience, but i did understand the message....i think. one day.......I'LL BE BACK!!! (terminator style)

[@vadimprudnikov9072]

I'm sorry, I just have one suggestion. Dave, could you please try making you talks shorter? I often catch myself drifting away... In my opinion, sometimes, there are too many words around a tiny thing.