A microservices architecture is an approach to software design where functionality is implemented across a suite of small, independently deployable services. This design means it can be changed, updated or even have a new service added to it relatively quickly and without fear of it affecting other parts of the platform.
That means big benefits for our customers:
Smaller services (code bases) mean faster delivery of new features and code updates.
- This design also means that when a change is made, we can immediately know if something isn’t working as expected, and simply rollback that change.
Each service can be independently, elastically scaled in real time. This means, for example, when one customer suddenly starts making a large number of API calls to the Search engine, no other parts of the platform are affected, and the Search service can spin up all the resources it needs to keep on running.
- Usage can be scaled on demand and balanced across dynamic resources. Said differently, scale works in both directions. If something doesn’t need resources, it can be scaled back and resources can be allocated to other services for overall optimization.
We use feature flags to decouple the deployment of new functionality from its enablement. So we can “try-out” a new service (or changes to a service) on a handful of orgs before rolling it out to everyone.
- Changes to individual microservices are contained, which limits the risk of unintentional effects to other parts of the system.