If you're interested in a general introduction into microservices, as well as getting a taste of my latest book, then the first chapter of Building Microservices, 2nd edition is for you. Details on how to download for free here: .
My new book, Building Resilient Distributed Systems, is now available in early access form
@OReillyMedia
. A few chapters are available at this stage, ahead of the planned publication in August next year. You can find out more about the book here:
Lots of people worried about Microsoft’s acquisition of GitHub. I wonder how many of those people are familiar with the Microsoft of today. There are few other similar large companies I see who so consistently focus their efforts on making developers lives easier. Relax a bit!
A big day - got to hold a copy of my new book, Monolith To Microservices! It won’t go on sale in dead tree version till the end of November, but great to see this rush copy.
If you make a decision to build a microservice architecture, then you don't get to describe all of the complexity of distributed systems as "accidental". That's like jumping into a den of lions and describing the resulting injuries as being an accident.
I've come to the conclusion that there are two golden rules of distributed computing. 1.) You can't beam information from point A to point B instantly. and 2.) Sometimes the thing you want to talk to isn't there. All other challenges of distributed systems flow from these rules.
My view on microservice architecture certification?. If you come to one of my microservice workshops and want a certificate, I will happily provide a one that certifies that "You were there when certificates were handed out".
So if you’ve just purchased a company that uses microservices and want to understand what the hell they are, and whether or not turning them off randomly will cause issues, this might be helpful:
Let's get real for a moment. If you're a dev, 75% of your time is going to be spent taking stuff out of a database and putting it on a screen. If you're lucky, some of that remaining 25% will involve you taking stuff off a screen, and putting it into a database. Then death.
my typical day at Google:
9am - reverse a linked list
11am - count unique ways to climb a staircase with dp
12pm - lunch
3pm - help animal escape NxM matrix efficiently
4pm - invert a binary tree
5pm - commute home using Dijkstra's
So, rather than screaming into the void regarding my thoughts on Platform Engineering, I thought I'd just scream those thoughts into a blog post instead - Don't Call It A Platform:
Dear Software Vendors. On your website, I need screenshots of your product at an absolute minimum, and ideally I want a video showing how it is used. Don’t make me sign up for a demo to see your product.
I’m really hoping that the new fondness for Architectural Decision Records results in better critical thinking and internal communication, rather than just more ceremony.
I’m working on a new thing! Early access version of my forthcoming book “Monolith To Microservices” is now available. . It’s very much a rough draft, and only part of it is up so far, but feedback is greatly appreciated.
Well, the 2nd edition of Building Microservices is off to the printers. Ebook release in about a week, print books arriving in the US and EU/UK in around 3-4 weeks.
True story: I once joined a project where the lead was very proud of the test suite that “never failed” and had “100% test coverage”. He was right about the coverage. The reason the suite never failed? Not a single assertion anywhere in the suite.
Microservices are not the antithesis of a modular, monolithic architecture. In fact, I'd argue that a modular monolithic architecture and a microservice architecture have much more in common with each other than either styles do with a big ball of mud.
I think if your tech lead acts like this, they don’t know what leadership is. If you think this is what leadership is, you haven’t worked with good leaders.
An anti-pattern is just a pattern used in a sub-optmial context. A good practice is just a practice used in the right context. You shouldn't talk about patterns and practice being "good" or "bad" without talking about the context in which they will be used.
So a few people have asked why I have this snarky response. What is my problem with this service? Well, to be clear, it’s not an issue with GraphQL, it’s an issue with direct coupling with underlying datasources
#thread
Am I alone in not liking the term “platform team”? Makes me worried that the team just ends up focusing on the tooling, rather than their actual job which should be enabling other teams to do their job. I much prefer “delivery support” or “delivery services”.
Saying a software architecture is “bad” isn’t terribly helpful, and misses the point. All architecture ends up being optimised around something, and the goals and constraints you now have may just differ from those people who came before
In my experience, a lot of BPM tools are predicated on the idea that non-technical users will expect to design business process using the tools, but that this never actually happens. So we get the complexity without the benefit. Is this what other people see?
If you don’t own your part of the customer experience, it’s pretty hard to create an autonomous customer-focused delivery team. Continuing to have dedicated front end teams is all too common for “microservice” organisations, and misses so much of the point of a ms architecture
Probably controversial hypothesis: the emergence of Kubernetes and the surrounding ecosystem of tools is enabling enterprises to remain stuck in the sunk cost fallacy of running things on premise.
Just saw a job add for “Head Of Software Development - Frontend”. There is nothing better for slowing down your pace of change than enforcing organisational silos.
I had a lovely chat a while back with
@martinfowler
about the merits of microservices, and when (or when not) to use them. It’s now available as a podcast: thanks to
@GOTOcon
So, some fine clickbait bullshit here. Am I going to read your report? No! Does it imply you don't know what DevOps is? Yes, clearly yes. If this is the mindset behind this company's products, they've done a great job and steering me well clear. 🤦
DevOps is dead, platform engineering is in… or so people say. 👀 The first-ever State of Platform Engineering Report is here to set the record straight. 🧠 Get 🔥 insights from top performing orgs and platform veterans👇
I’m getting close to finishing up the 2nd edition of Building Microservices, working towards publication in August. If you can’t wait for that, and want to read the book in early access form, then you can read it on
@OReillyMedia
’s online platform:
@QuinnyPig
@awscloud
Boris Johnson has been deprecated and will be EOL this autumn, to be replaced with a brand new service which does 75% of what the old one did but in a confusingly different way and yet also costs you more money.
The fact that the same organisation can talk about DevOps and Fullstack, and yet still be happy with silo'd frontend and backend teams will never get old.
Almost 2y, ~280 pages, ~110 diagrams, tens of conferences around the world, 16 workshops, uncountable evenings and weekends spent on my laptop… and it is finally READY 🚀 🎉
Building Micro-Frontends is the book where I reversed all my experience on
#microfrontends
🧵👇
I’ve lost track of how many times I’ve pointed people at this talk on Sagas in distributed systems by
@caitie
- such a great summary of the concept with enough real-world detail that people can work out how to actually use these things:
So much great stuff in this
@infoq
article about
@github
’s process of migrating functionality to microservices. The query watcher for helping data decomposition is genius! Thanks to
@StartupSha
for sharing this!
All abstractions hide something. Some may hide too much for you, or hide too little. Some will be perfect, just for you. But no abstraction is perfect for everyone.
Interesting side effect of the Cloud Native Foundation is now that I’m commonly speaking to people who believe it can’t be cloud native without Kubernetes 🙄
So is there any reason why I can't describe the use of DB read-replicas as a form of caching? Reads from the replicas might be stale, invalidation is a concern but handled by the replication technology. Conceptually, it's a cache - albeit one with limited general applicability.
I will not be speaking at DevTernity on 7th of December as previously planned. Unfortunately it turns out aspects of the conference were misrepresented to me.
@SaintFrankly
No worries Francis - I used to live in Australia so I get this a lot. You should see the emails I get! The people who agree with him are the worst. PS my Aussie wife is a fan of yours and says hi!
I’ve heard some fun alternative terms for legacy software in recent years:
- Heritage
- Legendary
- Classic
The most common alternative term for “legacy” software that I’ve heard used recently is course deeply unfortunate - “monolith”.
Last week, we agreed at a client to replace the word "legacy" with "revenue generating".
Instead of "don't make me work on the legacy software"... 💀
Say "Actually, yes - I'd like to work on the revenue generating software" 💰💴💵💶💷
#NoLegacy
I’ve said it before, and I’ll say it again, you’ll never appreciate the true horror, pain, and suffering a Microservices architecture can cause until it’s running in production and serving actual traffic.
Let’s return briefly to where we began. Why have
#microservices
failed in so many places to date? - iI've argued that it's because the intended architecture, if there was one, didn’t get shipped to production.
To be successful, an architecture needs to be RUNNING.
A nice (and brief) overview of why
@shopify
went for a modular monolith over microservices by
@kmkwesteinde
. I’d love to see/read a deeper dive on this as well, but I really enjoyed this overview of what drove their decision making.
Reminder for everyone who is looking for something to do in lockdown that my new book Monolith to Microservices is available now, more information on my website:
So, as far as I can tell, GraphQL basically breaks caching via CDNs or reverse proxies, unless you do a bunch of work on top. Is this an unfair statement?
I have a youtube channel where you can find playlists with many of my conference talks and interviews I have given over the years. Lots more content to come over the next few weeks, so please subscribe:
Trying to come up with some (non-exhaustive) pictures to help categorise different styles (and supporting implementations) of microservice-to-microservice communication. Thoughts on this one?
I've updated the page on Building Microservices, 2nd edition, to detail confirmed translation plans, and to add a full table of contents so you can see what you can expect when the book arrives in August.
Over the years I've become convinced that to get the most out of microservices you need to see them as style of modular architecture - with the added complexity that rather than in-process calls between modules, we instead have to deal with the horror of networks.
It’s interesting to see more content in this space, but the idea that using domain-driven design with microservices is somehow new is kinda odd. This is really of most interest in terms of what uber does internally, rather than a wider discussion of these ideas.
“Domain-Oriented Microservice Architecture” thus draws heavily from established ways to organize code such as Domain-driven Design, Clean Architecture, Service-Oriented Architecture, and object- and interface-oriented design patterns.”
AWS is way behind on offering sensible cost controls, and it could end really badly. Good coverage of this via
@QuinnyPig
and a recent
@InfoQ
article by Renato Losio . AWS can and should do better - this is a fixable problem they don’t care enough to fix.
The responses along the lines of “he should’ve figured it out and not racked up such a big bill” shows what’s wrong with society. Great you’re an AWS expert who knows how to prevent this. This is a student trying to learn and changed a setting that he didn’t understand
This talk by
@adrian_trenaman
from Gilt/HBC was one of my favourite talks from this year’s excellent
@qconlondon
lineup - great stuff on streaming vs batch, Kinesis, and towards the end Kafka. Highly recommended.
There have been a lot of comments around this post from the Uber engineering team, highlighting the fact that some prior art here is misunderstood, with other ideas being presented as coming from Uber despite being well established prior art.
#thread
1/17
It’s interesting to see more content in this space, but the idea that using domain-driven design with microservices is somehow new is kinda odd. This is really of most interest in terms of what uber does internally, rather than a wider discussion of these ideas.
A quick note on people asking me to speak at conferences. If you're trying to make your event sound appealing by telling me the names of the other people you have already booked, then don't be surprised if when it turns out they're all white men I decline.
Those of you stuck at home might want something to add to your reading list. My new book Monolith to Microservices is available now, more information on my website:
If you want to know more about breaking apart a monolith my book has that covered: For a brief snapshot of some of the topics in the book, you can also watch this video:
So if you find yourself constantly having to change your middleware, be it an ESB, API Gateway or Service mesh, take a pause for a moment and ask yourself if your architecture is working for you, or are you working for your architecture? 18/18
This shouldn’t be a surprise. Git was designed to make merging fast and easy, and this was a key requirement for managing with the kernel source code. The fact that people now abuse git branches to *avoid* merging and continuous integration isn’t really the tools fault
Does your application talk to a database on another machine over a network? Then you have a distributed system! Most people work on distributed systems - some just show the pain in a more obvious fashion.
The golden rule here is never expose anything until someone actually needs it. Think outside in - what exactly do external parties need? This allows you to be selective in what you expose. Too many people think inside out, and expose everything in case it *might* be needed.