211 34 Malmö
Sweden+46 735 124 email@example.com
Software has been moving away from monolithic structures with hard yearly releases for quite a while now. As the cycle of obsolescence quickens businesses need to build their technical solutions to be more flexible, pivotable, and upgradeable to be able to cater to the market and to changes in the society. Continuous research and development are cheaper than sparse releases in the long run. Proactivity trumps reactivity.
At Kruso we have been developing, exploring, and innovating in the digital realm for over 20 years. That is about 2000 years on the internet, and as you might have guessed we have seen a lot. Ideas have been explored, methods have been tested and theories have been proven or disproven. In this series of articles, I thought I would spare you years of experience and get you up to speed on the latest in tried and tested techniques for creating digital projects built with the future in mind.
In this section, I could be talking about how costly it is to develop and maintain a big monolithic system. The struggles you face when you have little to no insight into the inner workings, or when you lack access to the complex business logic that makes up your company’s digital platform. Instead, I'm going to start this section off with an old (albeit somewhat cliché) statement, but that will lead to more fun and inspiring point than just “you should take these steps to stay afloat":
Businesses must move quicker today than they used to, especially within the digital realm. This movement is mostly perpetuated by two forces: technology and people. It's a cycle that starts with a user need that in turn triggers a new technological or conceptual innovation that creates a new user need that in turn triggers an innovation that in turn... You get the point. This has been true since the beginning of technology and if Newton would've been alive today I'd Tweet him and ask him to make this an addendum to his laws of physics because this is as close to a force of nature as it gets.
As businesses compete to earn bigger market shares, they all race to improve their product as quickly as possible, and with every new update, the user gets accustomed to the new speed. Every iteration shortens this cycle of obsolescence. Releasing one big yearly update to your software just doesn't cut it anymore.
You might remember an old, ancient legend of a dragon by the name of Myspace, slain by a small college boy called Mark Zuckerberg. Like all legends, it doesn't really tell the full truth.
It's true that Myspace's market shares were taken over by Facebook, but it can be argued that the only thing that Facebook did to deserve this was being quicker, leaner, and more flexible, and that Myspace's demise was mostly their own doing. Myspace wasn't built with the future in mind and was hard to update and maintain. This, coupled with the fact that they were bought by the "old media" giant News Corporation and had to go through all of the slow-moving "old media" hoops meant that their monoliths release cycle couldn't keep up with the cycle of obsolescence. While they were occupied with slowly putting out fires, Facebook already had that sorted and had time to landscape and experiment with new types of trees in their forest.
This is just one specific example of many, but this general concept can be applied to all businesses and their competitors - big or small. The change will happen whether you want it to or not. Keep up with your audience because someone else already does.
So how can a business thrive in this never-ending sea of daily innovation, optimization, and ever-changing digital landscapes? All of this might seem impossibly daunting to think about at first, but as they say on the daytime mail order TV-channels (partially slain by streaming and replaced by targeted ads on social media platforms): Fret not, there's light at the end of the tunnel!
Circling back to the cycle described above (pun absolutely intended) we know that the core mechanics of staying relevant is how well you innovate for your audience. So how do we build a digital platform that allows innovation? How do we set up the optimal conditions to sync our release cycle with our users? How do we design a digital architecture that doesn't grow into a big, stale elephant that gets in the way of itself? I'm glad you asked. Let me introduce you (if you're not already familiar) to the greatest innovation in buzzword technology for the past couple of years: Microservices. Boy, do we love them?
For the uninitiated, the concept is simple: We used to build one big monolithic colossus of a machine with hard-wired connections to a large amount of tangled, hard to reach parts that may or may not be connected. Today we instead treat a big service as many small services. All services have their own jobs and purposes but are very good at speaking to each other. The services are not tangled and can be updated and maintained individually from one another and replaced or extended as the need (or will) arises. It's a bit like LEGO, but digital and with a lot more possibilities.
For those of you who like lists, here's a list of pros, in favor of microservices:
Cheap: Although the initial cost could get a bit higher than a monolith, this is a cost that is greatly saved over time. Small separate services are easier to maintain and reason about.
Safe: Features can be tweaked, developed, and maintained individually from one another, and new features can be tested without risking the stability of the system.
Quick: Since it’s a system built to be modular, we don’t have to put on our code archeologist hats every time we want to add a new feature or extend an old one.
Pivotable: All the points above combined means that the platform can move in any way needed. From a big perspective we can follow user needs and societal trends, from a small perspective we could find a service to be so good that it becomes its own product that could be leased out to other companies with similar needs.
So “what is the catch”, you might ask? Well, truth to be told there are many. Microservices, just as monoliths, can get tangled, the business logic can get obfuscated and development can get rough and rocky - it’s all a matter of implementation. In the same way, a monolith system could also be modular and maintained by different teams.
The big difference with a microservice architecture is that modularity is built-in on a conceptual and fundamental level and which allows us to work with individual deployments and individual scaling from the get-go. Your users suddenly start uploading a lot more images to your platform than you anticipated and built for? No need to go through the system to look for points of optimizations, just optimize and scale up your upload service. Need to implement a new payment solution? Easy! Just go to your payment handling service and implement it. A new interesting AI-powered solution on the horizon? Give it a go by deploying a small prototype and see what your users think. If they like it you can scale it up and connect it to more of your services, and if they don’t you can just roll back to the previous solution, even if the system around it has changed.
Working like this makes your big system more flexible while still being less prone to having the common problems you find in big systems, and if they would happen to arise, fixing them is vastly easier. Sleeping calmly at night gets easier too.
The easiest way of avoiding any trouble though is having a solid start, but it’s not always clear how that solid start looks. What should you focus on? What should you avoid? What should you be mindful of? Well, looking at the current word count, that is a question better suited for parts 2 and 3 of this series. There I’ll get into the nitty-gritty by sharing a collection of battle-tested tips and tricks to get you going on your journey, whether you’re a team starting a new product or a company in need of an update of your system.
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 in the first place.
See you in part 2!