Before you read any further: this will be a technology-heavy blog post. If you're not interested in the cogs whirring away inside an online platform like this one, we'll forgive you for giving this one a miss.
Justin previously gave an explanation of some of the technologies that we're going to use to build LITE and how we chose them. It's worth taking a moment to discuss how these technologies will benefit users of the new service and provide the development team with the capability to meet the range of demands being placed on them.
We're using microservices, and here's why.
Better software development
Technologies like Docker and Kubernetes are relatively new, but rapidly becoming mainstream. Google, BBC and Netflix (among thousands of other major organisations) are using these tools to build highly scalable and highly available systems that are backed by microservices.
Essentially, a microservices software architecture is just a way of building software in lots of small, individually deployable pieces, rather than one large program (often referred to as a "monolith").
At this scale, developers can reason about and fully understand the impact of a change they're making, reducing risk and the chances of introducing bugs.
An added benefit of small, succinct code is that it's easier to automatically test (via unit testing and other methods), which gives further assurance that bugs aren't being introduced by changes.
As all of the services interact with each other via an agreed contract, changes that might break other parts of the system can be more easily identified, understood and managed.
This all makes for a more reliable and bug-free experience, and keeps development moving quickly.
Tightening the feedback loop
The software industry gold standard for how to run projects is now, without a doubt, the agile methodology. One of its core fundamentals is getting feedback quickly and iterating the design based on that feedback.
Getting quick feedback is reliant on being able to show off your work. One of the best ways to do that is to deploy it to an environment where others can see it (a testing or staging environment).
To this end, Docker and Kubernetes act as a cutting-edge deployment mechanism helping our development team to tighten the feedback loop.
Enabling continuous delivery
The traditional method of delivering software via a so called "big bang" release (after weeks or months of development) is going out of fashion – and for good reason. Software is of more value to everyone if it can be released and updated more rapidly, incorporating feedback and changes as necessary.
An ideal situation is one where we're delivering updates to production systems on a regular basis – potentially many times per day. That might sound risky, but it's actually one of the best ways to remove risk from software development.
If changes are so small, and so easy to understand that they can move through your entire development, QA, build and deployment pipeline in a day, the overall risk is significantly reduced. From an operational perspective, smaller, more regular changes are also easy to manage, test and revert if there's a problem.
Seamless upgrades
Kubernetes and Docker allow us to move away from an era of deployment where a whole system is turned off for a few hours for maintenance and upgrades. We'll be able to upgrade small parts of a system at any time – no more 'Service temporarily unavailable'.
We can react to problems faster, with no need to wait until the evening or weekends to release crucial fixes or changes. We can test changes with a subset of the user community before performing a wider roll-out. We can A/B test changes (by providing two different implementations in parallel).
Most importantly, if changes have adverse effects we can roll them back easily and investigate further.
Building an open architecture
During the alpha and early beta, we've been producing a set of building blocks that allow us to deliver a first class export licensing service. Later other licensing regimes related to export controls can be brought on-board, so that exporters have a single, consistent way to interact with government.
A services-first approach enables us to easily on-board other development teams (who could even be using different tools and programming languages). And we can change or add to our own software ecosystem as the requirements and approach for these other pieces of work starts to become clear.
What's the impact on the project?
These benefits don't come for free. Some of the challenges that we face are around log management and debugging – in that when a problem comes up, we have to be able to identify which part of the software ecosystem is causing it.
As with everything in software, we're making a trade-off, balancing the day-to-day costs of microservices with the benefits of faster deployment, a tighter feedback loop and a more resilient software solution. We believe the trade-off is worth it, and that we'll provide a more stable and maintainable service for our customers.
Leave a comment