A microservices architecture is an approach to software design where functionality is implemented across a suite of small, independently deployable services. Microservices themselves are targeted and powerful engines for processing specific IdentityNow actions efficiently. They're also containerized so that our engineers can develop, deploy, and scale changes independently and quickly. Microservices are a key component of any market-leading, cloud-based product like IdentityNow.
NOTE: For more general information about microservices, see https://d0.awsstatic.com/whitepapers/microservices-on-aws.pdf
Why Microservices?
We're here to help you grow, expand and innovate, securely and confidently. To do that, you need IT as a partner in your strategic initiatives, not a policy and process bottleneck. Microservices are way to precision-tune our platform, so that security, control, and convenience are injected into the DNA of your business solutions. In other words, they help us improve the stability of the system as a whole and enhance our framework to accelerate deployments and adjust to system requirements over your business day.
As we continue to build out our microservice architecture, we can offer:
- Speed
- 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.
- Scale
- 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.
- Safety
- 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.
