Taking a pragmatic approach to microservices design
When it comes to the microservices architectural pattern, typically the model is to “dream small” while designing services. But how do you draw useful boundaries and focus on the minutiae, while still keeping an eye on shipping product?
A friend of the Frontier Podcast and an expert in such matters, Daniel Knight can offer insight into what a pragmatic approach may look like. As the former Director of Engineering at a high growth company, he oversaw financial products for the cards division. His work life is dedicated to mentoring encouraging developers to stretch the architectures the can use.
Dreaming Small
Knight laid out how he breaks down business problems into specific objectives and shifts the priority away from solving problems people don’t yet understand.
When it comes to how he looks at microservice architectural patterns, Knight has developed a theory that encourages product teams to focus on the what, while engineering teams can focus on the how.
A lot of microservice architecture theory talks about dreaming as small as you possibly can. This view is a great way to ensure that you’re focusing on development, but Knight is quick to stress that it’s also important to deliver a product.
So how small can you dream? Knight’s system for using problems to triage objectives involves a unique take.
Knight:“One of the things that the team does is we really take a pragmatic approach to microservice architecture in that we try to solve the problems that we know we have. We don’t try to solve the problems we don’t know we have.”
Define Problems Into Objectives
Before considering or conceptualizing the architecture, he encourages his teams to look in detail at what is known about the problem. He expects each developer to be able to understand and problem-solve within the specific domain.
Once established, the problem then gets broken down into responsibilities. This involves asking the question: What are some key functionalities inside that problem domain?
This approach encourages the kind of creative thinking to make the problem self-contained, and to decouple; this then lets you create a microservice.
Knight:“To give an example, when we were asked to basically take a monolith application that was responsible for a pretty massive ETL project ─ ETL being extract, translate, and load ─ we really looked at it and said, “What are the responsibilities within that problem that we have to really get right?”
Creating these natural breakpoints for the microservice architecture allows teams to be pragmatic, and ensures that teams are creating the simplest solution to knowable problems.
The Significance of Team Synergy
This kind of problem-solving based thinking is important when looking at the blurry line between product and engineering. While they’re decidedly different disciplines, they are naturally entwined and frequently converge.
Rather than worrying about this problem, Knight advocates for a continual learning process for all teams. Celebrating and encouraging a willingness to learn is a huge part of creating effective teams.
Knight:“At the end of the day, it’s all about delivering value. How can we create it? How can we get to learn and how can we get to production faster even if it means that we have to do things creatively and do so without sacrificing technical excellence.”
This is vital: product’s job is to ensure that the engineers are building the right things and they’re going to deliver value. This involves being able to trust the team – trust that they have done their research, talked to customers and listened to stakeholders.
Product’s job is to come with the “what”. Engineering is to come up with the “how”. An open dialogue and conversation between the teams and a commitment to learning is key, which doesn’t necessarily have to be a frictionless exchange.
Knight: “I expect to hear them having arguments. I expect to hear them talking over each other because, in the end, it shows that they’re both passionate and they’re both doing their jobs.”
This open environment of people being given agency over their role, and a passion for creating the best work they possibly can, allows a focus on dreaming small while still being able to deliver. Best of all, teams can ensure that they are delivering the highest quality code, with the maximum value attached to it.
Gun.io understands the DNA of an effective team because we’re built by engineers, for engineers. If you’re looking for another contributor to your team who brings more to the table than just their development chops, get in touch – we know some folks.