006 Applications, Microservice Mistakes and Getting Things Done
Don’t miss another newsletter by subscribing below :)
Application Architecture as Code
One my favourite people in the industry is back again with another featured article. Gregor Hohpe makes an excellent case in this post for how important automation is when you’re building modern systems.
Cloud without automation is just another data center
What I find incredibly interesting about this post, is how Gregor ties the architecture of a system into the actual code you write. I spoke about a similar topic at the recent AWS Community Summit.
With modern. serverless systems, the line between ‘infrastructure’ and ‘application’ code becomes blurry. If you are pulling message from a queue and starting a business workflow, well that’s an application decision.
So how can you define your application architecture using code? Using the power of cloud development kits. These wonderful IaC tools that allow you to define cloud resources using programming languages of your choice.
Now, you have the power to create abstractions that represent your architectural intent. And implement them using real programming languages.
Brilliant! Check out Gregor’s article for a deep dive. One more quote from the article before you do though
Document-oriented automation languages don’t represent data or control flow across application components well.
Enjoy
Million Dollar Microservice Mistakes
I find this such an interesting view on microservices. From someone who was there in the trenches at the dawn of the buzzword.
Microservices are great in the right hands. But the promise of ‘simplicity’ microservices bring is a misnomer.
It might make your applications simpler, but the infrastructure and integrations to make things work certainly get more complex.
In the land of the monolith, integration is as simple as a method call within the same process.
In the land of microservices, this simple call needs to traverse a network. And networks are hard, just go Google the fallacies of distributed computing.
They create separate “DevOps” squads or teams to manage Kubernetes clusters, centralized CI/CD pipelines, infrastructure, and automation. The outcome? Developers find themselves working in a ready-to-use yet restrictive environment, far from the promised autonomy of the microservices approach.
Any article with a call-out to Conway’s Law is always worth a read.
So before you decide microservices is right for your next project, give this article a read.
Getting Shit Done
A minimum viable architecture (MVA) is something I am a huge fan of. I’ve spoken with people who have been scarred by enterprise architecture teams, big upfront design and waterfall projects.
Architecture doesn’t have to be that way.
Architecture is an enabler, it allows you think deeply about a problem before you start building. But getting ‘just enough’ architecture is difficult.
This article proposes a set of criteria you can use to define a definition of done (DoD) for your architectures. To ensure you consider the architectural characteristics that are important to you.
So instead of spending weeks and months drawing diagrams and documenting decisions. You can align your architecture to the things that matter most to your business. Once you’ve addressed the things that matter, you have a minimum viable architecture.
Once you have an MvA, you can move on and start building. Safe in the knowledge you’ve thought about all the key components of your system.
The product evolves MVP by MVP. Each MVP should ideally increase customer satisfaction with the product, while each MVA should increase the system’s quality while supporting the MVP delivery
This article also discusses why continuous deployment is vital for success. Honestly, if I was to build a brand new application now. The first thing I would build is my pipeline. Once you can ship changes quickly and safely, well the rest is easy……
Don’t quote me on that.