Building Web-Based Applications with Microservice Technologies

As applications rapidly migrate to public and private clouds, application developers like me are expecting more from traditional enterprise infrastructure. Simply providing servers and storage in a corporate data center, even in a cost-effective way, is no longer adequate. Inside NetApp, our IT Infrastructure team embraced this demand and built a highly automated, self-service, cloud-based application development platform called CloudOne.

CloudOne was built for the rapid onboarding and delivery of integrated software development pipelines and new application run-time environments (for example, containers). To effectively use the platform, we needed an application development framework. As a member of the application development team, I became the domain architect for the new CloudOne Business Resilient Applications (COBRA) framework.

COBRA Framework

• The client is the web or mobile application. The application can be built with any technology that can make HTTP calls to the UI gateway, even though Angular is the preferred client framework for building a single-page application.
• The UI gateway is the entry point for the client to access back-end services. The UI gateway handles all calls from the client to the services, routing them to the appropriate containers according to the internal configuration. Anonymous calls are allowed for certain routes, but if a user wants to log in, the login is handled by the UI gateway. It also handles user authentication that uses OAuth 2.0. Any identity provider that supports OAuth — for example, Google or GitHub — can be connected. The UI gateway is technically a microservice. 
• The microservice environment runs in CloudOne and is accessible only through the UI gateway. Each microservice is like a standalone product: It has its own repository and build/deployment pipeline, and it runs as a pod on its own. It’s accessed by other services, such as the UI gateway or any other microservice in CloudOne. It isn’t directly accessible from outside the environment.When a call is made to a microservice, a security token must be added to the request. The UI gateway does this automatically, even for anonymous users. This action requires services, which call other services, to obtain a security token from the UI gateway before making the call.Although microservices can be built with any technology, we used Java and Spring Boot for our framework. In certain cases, developers may use other technologies if they provide substantial reasons.
• Internal boundary systems are our major legacy applications like Oracle Enterprise Resource Planning (ERP) and SAP CRM and are accessible only in the corporate network. The CloudOne environment, though, doesn’t allow any direct access to the corporate network, which is why all calls to these systems need to get routed through a specific API gateway. This approach provides an extra level of security