Introduction
In previous blogs, we have introduced Kubernetes and Microservices and discussed its impact on Network Operations. We also looked at the ways services can be published and how Kemp Ingress Controller can be used to do this, even alongside monolithic applications.
In our final blog of the series let’s look at the impact moving to a microservice application architecture can have on workflows, specifically with respect to role-based access control (RBAC) between development and network operations teams.
Maintaining Required Network Control
With traditional monolithic application delivery, developers are typically allocated specific endpoints on which applications are hosted and look after the building, upgrading, and release of new versions on a semi-frequent basis. Network operations teams focus on ensuring these applications can be reached. Typically dealing with the underlying network infrastructure including application delivery tasks such as Load balancing. SSL Offloading & Certificates, Access Management, and hostname or URL-based traffic routing. In this organisational structure Development and Network Operations work hand-in-hand and where changes are needed common workflows are followed (Change Requests etc). This ensures clear demarcation points between the teams.
With the move to microservices, there are several changes to how Development Teams Build and release Applications. Typically (as a major benefit of microservices) applications are updated and changed more frequently. The Network Infrastructure however does not change in the way or with the same frequency. What changes is how Application publishing is done and this typically is more aligned to the development workflows than Network Operations Workflows. This can bring challenges in maintaining the control required by Network Operations while utilising the fluid web architecture of microservices.
In this architecture, How do we prevent Dev Teams needing to get Change Requests approval for all updates from Network Operations. While at the same time prevent Dev teams from having control of the Network Infrastructure?
How do we prevent Dev Teams needing to get Change Requests approval for all updates from Network Operations, but at the same time prevent Dev teams from having control of the Network Infrastructure?
A common approach is a move to Dev-Ops teams managing all aspects of the application and much of the existing recommended strategies for Microservices assume this flat Dev-Ops team structure. The reality for many organisations though, is that it is not feasible or desirable to move to this model due to regulatory requirements or where personnel mismatches.
Service Mode for Microservices
For the problem outlined, Kemp Ingress Controllers supports a limited Service mode for microservice application publishing. Service Mode lets Network Operations Teams give Development Teams the ability to publish their Application using Kubernetes without giving them access and control to the underlying network infrastructure. No Ingress Resource is defined by the development team and instead, this is managed through the Kemp LoadMaster
The workflow is quite simple
- LoadMaster is integrated with Kubernetes Cluster using Kemp Ingress Controller and Service Mode enabled
- Development Team Request a new application endpoint for publishing
- Network Operations create an endpoint(Virtual service) on External LoadMaster
- Network Operations assign the ID of this to the Development Team
- Development Team tags and annotates Service this ID
From this point on any changes to this actual application can be made without any interaction between the teams including the Scaling of the application. The benefits of the above approach are that the aspects of the application such as the IP Address, Port, Access Management, Web Application firewall, can all be controlled by the Network Operations Teams while the development team can manage all the internal applications aspects. When the applications scale up the LoadMaster will scale also automatically.
Ingress Mode
As well as supporting Service Mode Kemp Ingress Controller also supports Ingress Mode which can be used where Rules and annotations can be defined by the development teams and this mode is akin to the typical Ingress Controller operation in Kubernetes.
Support for both modes enables flexibility and allows for a more seamless controlled transition to microservice application delivery
Conclusion
When migrating to microservice application delivery team structures and network infrastructure roles must be taken into account. Adapting a solution that enables both the flexibility of microservices for Developers while maintaining the separated control of network infrastructure as delivered by Kemp Ingress Controller Service mode enables this challenge to be met. To take full advantage of Kemp Ingress Controller functionality see here…
The Ingress Controller Series
- WHAT IS KUBERNETES?
- IMPACT OF KUBERNETES ON NETWORK ADMINISTRATORS
- EXPOSING KUBERNETES SERVICES
- THE KEMP INGRESS CONTROLLER EXPLAINED
- A HYBRID APPROACH TO MICROSERVICES WITH KEMP
- MANAGING THE RIGHT LEVEL OF ACCESS BETWEEN NETOPS AND DEV FOR MICROSERVICE PUBLISHING
Upcoming Webinar
For more information, check out our upcoming webinar: Integrating Kemp load balancing with Kubernetes.
