The following design pattern is an example of how a technology shared service platform could be implemented on K5. The difference between this architecture and the previous shared services blog is that I’ve included our Inter-Availability-Zone connectors to provide an internal high speed link between the subnets in the different Availability Zones (AZs). It’s now possible to ensure your traditional style applications or cloud native apps can be easily distributed across the two AZs. The network traffic does not traverse the internet. The entire architecture that is shown below can be deployed automatically with minimal effort thanks to HEAT stacks, K5/OpenStacks Infrastructure Orchestration project.

Note for Native OpenStack Users : Both the InterProject and the InterAvailability Zone links discussed here are enhancements that Fujitsu have made to OpenStack Neutron API for use in the public cloud.

DMZ

The DMZ project is used to route traffic into and out of the solution. A proxy server could be used to provide/control internet access to the other projects. A https terminal server such as Guacamole could be installed in each DMZ to provide redundant access to the server consoles.

Two virtual routers are installed in each AZ. One manages all the inter-project routing and the second is used in conjunction with the FWaaS to control access at the internet boundary.  An optional public facing LBaaS instance could be used here to provide HA for the Guacamole service.

Shared Services

This project would be used to host all the shared services that you wish to provide to your other projects such as email (though don’t forget K5 does offer this as a PaaS offering too), file sharing, git repos etc. A network connector is used to link the shared services subnets between the availability zones which facilitates fast synchronisation of data between critical services. An internal facing LBaaS could also be used here if required. By design, these subnets have neither DNAT nor SNAT capability. It would be necessary to leverage a proxy service in the DMZ (not part of K5) to achieve this. The alternative would be to link this subnet directly to the internet via another virtual router breaking the model required 🙂

Department A/B/C…etc

These are the projects that the end users would consume. They can have the same HA features exposed to them that are in the Shared Services project. This model allows for quick and easy deployment, destruction, redeployment to meet demands whilst keeping the core services in tact.

Security Groups are used through out to also provide an additional layer of network security for all hosts.

Summary

The complete Shared Services model can be quickly and consistently deployed over and over again using K5’s Infrastructure as Code (IaC) HEAT Templates. More and more customers are leveraging models such as this to help them on their Continuous Integration and Continuous Deployment (CI/CD) journeys. If this is of interest to you I’d recommend that you also look at Cloud Foundry for rapid application development – K5 offers a Cloud Foundry platform too.

Happy Stacking.

#withk5youcan