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.
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.
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
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.
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
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…
For more information, check out our upcoming webinar: Integrating Kemp load balancing with Kubernetes.