Creating Thriving Digital Platforms Built for Innovation.

Spring is upon us. The sun is shining, the birds are slowly returning and people are once again starting to wake up from the long and dark Scandinavian winter slumber and congregate. In other words – it's time for the third wave of COVID-19, self-isolation, and this series.   

As usual, this will be much more fun if you have read part one and two, even though it’s not a prerequisite. This time the (very loose) theme will be how to easier handle work on a day-to-day and future basis.  

But if you want to be completely up to date on how to create thriving digital platforms built for innovation - take a look at part one and two.

Grab something warm to drink, and let’s go!    

A great benefit of microservices is that big projects become easier to manage as responsibilities are more clearly separated. We compartmentalize our platform, so it only makes sense to continue in this trajectory. Split up your big projects into task forces that can focus on making one single service excel instead of having to divide their attention between a lot of different areas and contexts.  

A fitting example of this is Amazon's idea of “Two Pizza Teams”. This means that they structure their platform in a way that every service is managed by its team that is just big enough to be fed by two (American) pizzas. This team is responsible for their service throughout that service's whole lifecycle. All the way from inception to production to maintenance, making them experts on their own states in the US of Amazon. Just like with real-world geopolitics these states abide by the rules of Amazon, but they also have the freedom to govern their state as they see fit for the needs of their citizens.  

Splitting up the responsibility creates more experts in your teams that in turn can help you make more informed and lean decisions.  

In a perfect utopia, our systems never fail. Probably because we have genius AI's that automatically audit our code and crawl around in our servers, intelligently anticipating, calculating, and fixing everything that goes wrong the same millisecond it happens. Unfortunately, the last AI I encountered thought that "January, February, Maruary, Apruary" was a terrific way to list months, so we probably still have a long way to go. Until then we (unfortunately) have to secure our systems manually.  

The good news is that microservices make this easy. First of all, having separate, well-defined, easily maintained services means that we've eliminated many points of failure straight out of the box. Secondly, compartmentalized code is easier to test, and if we went for the "one team, one service, one lifecycle" method of working we even have a dedicated team that knows all the ins, outs, and weak spots of the services.  

But even though we have all this, there will always be unforeseen points of failure, and that's why we have automatic tests and monitoring. By setting up systems that constantly observe our business-critical points we can make sure to always catch the errors in time. This gets increasingly important as the platform grows, but unfortunately, in most cases, it is only implemented after the lack of monitoring has been a problem for a little too long.   

Do yourself a favor and include time to set up monitoring in your development estimations. Both on a practical level, but also on a more theoretical one. See if there is a way you can standardize the way you monitor the different services. Explore different monitoring tools and integrations. It's easier (and much more fun) to do at an early stage.  

This is hugely important even if you don't work with microservices, but since we've touched on the topic of teamwork, I figured it could be helpful to include it as a separate tip.  

All teams have processes, whether we want to or not. They can be defined, or they can be implied. In any case, processes are what make or break teams. Processes are what make or break businesses. Healthy processes make work quick, fun, and efficient. Unhealthy processes make Jack a dull boy - exponentially.   

In a previous installment of this series, I said that a microservice architecture is a bit like LEGO ®, but digital and with a lot more possibilities. Let's run with that metaphor:   

Imagine that you have a huge box of mixed LEGO ® bricks in front of you in all possible shapes sizes and colors. Now, you want to build a big blue house, but you instantly run into trouble. The colors are all mixed, so you have to dig around in there to find the blue bricks, and the lighting makes it a bit hard to differentiate the blue bricks from the green ones. On top of that, they all have varied sizes so even when you find a blue one it doesn't always fit your current needs. You dig and you dig, and eventually, you build your house, but with sore hands, tired eyes, and a bad mood.  

Not having optimized and clear processes is a bit like that. The goal we set out to accomplish becomes complicated and tedious and gives us a bad mood. Imagine the same LEGO ® building session but with proper processes in place. You turn the light up, you have all your bricks sorted by shape, size, and color and you have soft gloves to counteract the sharp corners of the bricks (because for some reason your hands are super soft in this metaphor). You build the house quickly, have some extra time to improve on your initial design, and go to bed early with happy hands, eyes, and mood. What a delight.  

So, in the real world (outside of LEGO ® -land) this all boils down to standards and guidelines. How do we communicate between service teams? What does our release cycle look like? Who's in charge of testing and documentation? When is the latest we can make design changes before a release?   

Keep asking those questions until all your accumulated work is covered. Then map it out and ask yourselves what works and what needs improvement. And get comfy, because this is a process that will grow together with you, your team, your platform, and your learnings.  

Never seen that title for an outro section before, have you? Wink, wink, nudge, nudge, say no more. We’re nearing the end of this series. Hopefully, you found it helpful and interesting, and maybe just a liiiittle provoking or confusing. That’s good – it means that you are getting outside of your comfort zone and that you are learning new stuff.  

It’s been great fun writing this and if you read everything in one sitting, I hope that your eyes are still in their sockets and your brain in a solid-state. This is a huge topic that we love to think about, talk about and practice at Kruso, and hopefully, this serves as a good introduction to the topic for your future endeavors.  

The microservice architecture has been around for quite a while, and we're nowhere near the end of its relevancy. As with every other methodology it exists in its own state of "never finished" (a callback to Part 1 of this series), and new insights and developments are constantly discovered. Please feel free to get in touch if you have any thoughts, opinions, or comments in general.  

Until then: take care and remember to hydrate and stretch your legs once every hour. And good luck with whatever you do that made you interested in this blogpost.