About the Client
Nutanix is a leading cloud computing software company. They sell what they call hyper-converged infrastructure (HCI) appliances and software-defined storages. Nutanix was announced an MQ Leader in the November 2018 Magic Quadrant for Hyperconverged Infrastructure.
Nutanix works with large corporations and data centers all over the world. They maintain and manage millions of services every second.
Today, enterprise companies need to configure their resources one by one on various cloud services like AWS, Azure or Google Cloud. The services’ settings depend on the providers that have different instructions and features. All that configuration takes a lot of time and requires pros with special expertise to do it.
Nutanix’s clients are often not tech companies and they don’t want to employ technical specialists to orchestrate those services. Instead, they’d need resources expansion or status change in a technically simple way.
Quantum designed and developed an open-source SaaS solution to help Nutanix. You can find the project by following this link: https://github.com/nutanix/papiea-js
The solution we developed orchestrates services from a provider without intervention and helps customers change the state of their involved resources using simple instructions.
Our service connects four parts that help match abstract things with real-life needs:
- Client. A company that requires the provider’s resources.
- Provider. A company that has resources that could possess states.
- Spec. The desired state of a resource.
- Status. The actual state of a resource.
We used the Agile methodology to carry out the project. To ensure timely and transparent communication, we had 2-3 meetings per week with all team members on both sides (Nutanix’s and Quantum’s representatives).
Our customer had already developed a vision written in a design document. The intention was to have a DSL for managing statuses of resources. On our side, we analyzed this concept and developed a specific medium format, like JSON, for transmission and smart archiving of data in our system. After ensuring that the system’s architecture is robust and extensible, we continued further design.
During the next stage of development, our team built a basic API that lets saving status of a resource, specifically a service’s status, and information about clusters. Alongside the API, we developed an SDK, so that the developers on a provider’s side could use our SaaS.
Having providers covered, the team immediately started working on an API for clients. First of all, it had to provide a way of authentication and authorization of incoming requests. And it was the most challenging part of the SaaS because different providers (like Amazon) have different user roles. To tackle this problem, we analyzed all user roles that most popular providers have. After that, we came up with our configuration policy for different provider’s needs. So now, the API can match provider’s roles to their respective permissions.
Another challenge was creating a flexible permission system akin to AWS permissions. Different providers could have a different set of rules for accessing full resources or their parts. To solve such a problem an RBAC (Role-based access control) engine called Casbin (https://github.com/casbin/casbin) was chosen. It provides APIs utilizing a magnitude of programming languages as well as much needed flexibility.
Overall Authentication and Authorization diagrams look as follows:
After authentication and authorization, the client’s API had to be able to communicate with a provider and automate the orchestration of services on the provider’s side. To achieve that, we designed and built a medium called the Intentful Engine. It’s the core of the entire SaaS since it translates client intents into automated handling of provider resources.
Let's discuss your idea!
User-facing API & Provider-facing API:
2) NodeJs – fast asynchronous server, native JSON integration
3) OpenAPI/Swagger – API description & docs
4) Express – router for NodeJs server
5) Jest – unit/integration testing
1) ClojureScript – flexible easily-extendable functional language
2) Instaparse – parse/lexer ideal for building DSL (domain specific language)
1) MongoDB – NoSQL DB for storing schema-less data. Extremely good for scaling & modifying existing data