Scale can be one of the primary drivers in migrating from a traditional monolith to a distributed, service-oriented architecture, like microservices. Scaling the capacity to process high volumes of requests or data or scaling value delivery by breaking down a large application into smaller pieces that allow more people to work on it simultaneously can be achieved by adopting a distributed approach. A distributed approach’s capacity to eliminate bottlenecks and single points of failure can also unlock performance and reliability.
Like most things in this world, there’s no such thing as a free lunch, and the benefits of a distributed approach come at a cost. These include the increased overhead of building, deploying, and maintaining many smaller services, the communication overhead between the services and the teams that own them, and the increased surface area that many services present from a security and compliance perspective.
This panel brings together engineering experts to discuss their experiences navigating the development sprawl and the almost inevitable complexity of distributed architectures.
Architectures that are complex and tightly coupled are vulnerable to a cascade of failure from one system to another, while, depending on the implementation, a distributed architecture employing microservices is inherently more resilient because failure can be isolated.
Deploying microservices is more complex than deploying a monolith, but breaking a monolithic architecture into smaller microservices gives you the flexibility to pick the most appropriate technology stack, tenant, and database type, to deliver the required service. Deployments can be made without dependence on other teams, and again the effect of any failure can be isolated.
The use of microservices and distributed architectures can create complexity, particularly during the transition from a monolithic architecture where parallel systems must be maintained and synchronised, making debugging and the maintenance of the local development environment difficult. Microservices may also present a larger overall surface area than the monolith, meaning more complex compliance and security requirements.
Although testing individual microservice components can be less complex than within a monolithic architecture, constant change means that regression testing is especially important and up to date automated test suites are essential.
With microservices, the teams developing, testing, and maintaining them can specialise rather than require knowledge of the entire system, but this can become a disadvantage if limited resources mean that members must move between teams.
With the appropriate tooling and governance in microservices, complexity can be minimised. Tools such as Kubernetes are required for container orchestration, while appropriate object templates can be created and deployed to ensure consistency between environments.
As multiple teams work on different microservices, governance is essential to ensure that policies for security and identity management are implemented in a common and demonstratable way and are documented as such.
For testing, the tooling depends on the type of application, so the test team work closely with the developers from the initial stages on planning. They then know how the changes will affect the application and hence the tools required.
Conway’s Law suggests that software architecture and systems modelling follow the communication channels and structure that an organisation has, so with a monolithic business structure and code stack changes will be made very bureaucratically.
In contrast, although governance and standards are required to prevent inconsistency, a team working on microservices is empowered to own the entire process, from drawing up the user stories in conversation with the client over their business needs, to developing, demonstrating, refining, testing, and deploying each release.
Communication between developers and testers should ensure as much testing as possible is done at unit level to mitigate delays in deployment. This ensures testing is not left until the later stages and enables the team to concentrate on effective integration testing.
There is a danger that templates created from complex microservices are then used to create new microservices for tasks that do not require such complexity. This results in over-engineering, complicating the subsequent development and maintenance of those microservices.
It is also possible to lose sight of any loose couplings that still exist between distributed services, so unexpected failures are difficult to trace and overcome, particularly when using multiple technology stacks in various locations and trying to correlate events and information via extensive logs. However, advances in cloud-based tools, and particularly those employing AI, can help spot patterns and proactively detect such issues.
Another pitfall is that in testing global microservices there are factors you cannot control, such as, for example, how network traffic flow affects performance testing results.
Working with microservices, teams can develop and be ready to deploy services before the business is ready to adopt them. Thus, a business journey, as much as a technological journey, is required to manage this.
The key success in microservices and distributed architecture is seen in reduced dependency on other teams, enabling Continuous Delivery and Continuous Integration, so deployments and testing can be done independently. This is enabled by good tooling, and the right people with the right mindset and pipelines, able to deliver code changes swiftly and efficiently.
While a monolithic architecture may see releases a week or more apart, with microservices and an Agile approach to development and delivery, multiple small releases can be made daily with no downtime and reduced risk of cascading failure.
The route to streamlining an organisation and boosting productivity often lies in the integration of software to digitise manual processes or enhance systems. But how do you make sure you select the right solution for your organisation? Headforwards’ Product Manager Owen Hodge shares five things you should consider when deciding between fully custom or customised off-the-shelf software solution.
IT infrastructure and service provider, Softcat have been working on expanding and maturing their Cloud service portfolio. As their technology partner, Headforwards helped Softcat reimagine the interaction they have with their clients by delivering a Cloud Management Portal.
Quick start projects are a great way for businesses to kickstart innovations, make progress fast and overcome limitations around team capacity and resource. Learn more about the benefits.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770