With the rise of distributed application architectures setting up key technical questions for developers and IT, Brad Drysdale, APAC Field Chief Technology Officer at Kong, examines how software is evolving. He tells us: “The future of software is distributed, microservices-driven and polycloud.”
When you look at the technology operations of Australian enterprises, one does not have to dig deep to see the level of focus and investment being put behind software engineering. It’s all-encompassing, spanning talent, tools, culture and ways of work.
Whole industries such as banking are reclassifying and recasting the roles of their entire workforces as software engineers. It’s everything-as-code and software-driven. Software – to borrow a well-worn proclamation – is ‘eating the world’.
Engineering-led workforces are naturally keen observers for how software – and particularly the best practices for creating, deploying, maintaining and optimizing it – is evolving.
The future of software is distributed, microservices-driven and polycloud.
Monolithic architectures – in which the entire program is developed and deployed as a single application – are quickly becoming a thing of the past. Replacing them are distributed architectures, where applications are composed of microservices, containers and cloud services/APIs that may be hosted in different places but can be orchestrated to run together and to communicate with each other in order to form a functional product or service.
Microservices are one of the key building blocks of distributed architectures. Applications are split into sets of smaller, interconnected services – microservices – that can be deployed independently of one another. Each can be altered or switched out independently of others, cutting the time it takes to build, maintain and upgrade each one (to improve the overall application they are part of).
Meanwhile, polycloud means a single application can be assembled from building blocks hosted in multiple cloud environments. We know that different clouds have different characteristics that make them particularly conducive to certain workloads over others. Polycloud is about being able to plug-and–play all these individually-brilliant ‘blocks’ of code as and when you see fit.
While this is acknowledged to be the future of software – a recent survey found 90% of Australian enterprise technology leaders believe microservices-based applications are the future, and companies that cannot support distributed applications will suffer competitively – some key challenges and questions remain.
Specifically, these questions include:
- Do technology leaders and their organizations have the tools to support distributed architectures and microservices- and API-driven applications?
- Do they know how to innovate in that environment while meeting code quality, governance and security threshold standards?
- Can they do all of this at scale and at pace?
These are questions for which there are answers, but technology leaders and organizations vary in their capability and maturity in addressing them.
Rise of the service mesh
To answer many of these questions, technology leaders are increasingly turning to service meshes.
Service meshes have grown out of the trend towards decomposing monolithic applications into different services and components, where each component or service has a single role to play: one may perform user registration, another product lookups.
All of these services or components need to communicate with one another. They also need to be able to authenticate traffic flowing between them to make sure a service is who it says it is, as well as to control what kind of API calls might be made between the services.
A service mesh complements an API gateway in providing reliable, secure and observable connectivity between microservices in distributed, cloud-native environments.
Using a service mesh encourages a consistent approach to Zero Trust security between microservices; to the operationalization of visibility and control of services regardless of where they are running; to the meeting of security and compliance policies; and for supporting performance of all of these microservices at scale.
By letting a service mesh take care of these concerns, development teams can focus their time and effort on building microservices and APIs that add features and functionality to their core product, and that fuel innovation and value generation for the business.
Australian adoption
In keeping with the reputation that Australian enterprises have earned as early adopters of new technology, technology leaders are already embracing service mesh technology.
A recent study by Kong shows that 32% of Australian organizations have a service mesh in production, while a further 44% say they are in the midst of a deployment and an 20% say they intend to start deploying one within the next 12 months. This is strong backing for service meshes as a concept: only 4% of Australian firms don’t expect to be going down this path by mid-2023.
The same study shows that three-quarters of service meshes connect less than 100 services at present, suggesting that usage is still relatively nascent, in line with the relative newness of the technology.
The biggest drivers for Australian organizations to deploy a service mesh are to reduce costs (56%), followed by chasing service connectivity/service discovery/traffic reliability improvements (54%), zero-trust security of services (50%) and for compliance purposes (46%).
Due to converging technology trends, such as the mainstreaming of public cloud and the need for omnichannel experiences, business leaders must find new ways to connect increasingly distributed infrastructure and devices.
APIs and microservices are the key innovation enablers here, but they need to be appropriately supported by service meshes and API gateways. Doing so affords API – and microservices-driven applications, and the Digital Transformation initiatives they are being built under, the greatest chance of success.
