moving microservices from pilot to platform€¦ · •setting the strategy-outlining a...

RESEARCH BYTE

Scaling Up Enterprise KubernetesMoving Microservices from Pilot to PlatformJON COLLINS

TOPICS: DEVOPS DEVOPS AUTOMATION

CREDIT: IPOPBA

Scaling Up Enterprise KubernetesMoving Microservices from Pilot to Platform

TABLE OF CONTENTS

Summary1

Benefits and Challenges of Scaling Up Kubernetes2

Setting a Strategy for Broader Kubernetes Deployment3

Delivering the Platform4

Organizational Perspectives5

Planning for Success6

Key Takeaways7

About Jon Collins8

About GigaOm9

Copyright10

Scaling Up Enterprise Kubernetes 2

1. Summary

Over recent years, the Kubernetes orchestration mechanism has become the de facto target fordeploying microservices, to the extent that many enterprises are considering it in their softwaredelivery strategies. While organizations are embracing the principle of Kubernetes, far fewer have yetto deploy it at scale; Only 10% of enterprise respondents to GigaOm research, carried out earlier thisyear, have made use of the platform.

Figure 1: Enterprise use of containers and function-based platforms

If these are still the early days, and as technology decision makers look to build upon successful pilotsor smaller deployments, the question becomes: what comes next? Planning deployments firm-wide canbe daunting, as there is more to get right and, potentially, go wrong. The next steps will depend onwhere an organization is on its journey, the context, and the business goals as a whole.

In this report, we consider how to scale up Kubernetes, and ensure success, both now and in the yearsto come. Aimed at developers and development managers, application operations professionals, sitereliability engineers (SREs), technical architects, and IT strategists, this report consists of the followingsections:

• Benefits and challenges– scaling up Kubernetes and microservices for the broader enterprise,post-pilot.


• Setting the strategy- outlining a microservices-based infrastructure that delivers business value.

• Defining the platform- technology choices and operational considerations to ensure a flexibletarget for developers.

• Organizational criteria- ensuring the right non-technical elements are in place to move from an on-premises way of thinking to a cloud-native approach.

• Planning for success- summarizing the stages required to deliver on the potential of Kubernetes-based microservices.


2. Benefits and Challenges of Scaling Up Kubernetes

The benefits of Kubernetes align with the broader benefits of microservices-based deployment:enabling more modular, scalable applications to be built. Done correctly, modularity is more efficientand has faster delivery. You can read more about the benefits of microservices in our companionGigaOm report, “How to Benefit from Microservices.” From the process perspective, developers create,build, and test microservices using a development toolchain, which is then deployed in (Docker-based)container form, into the Kubernetes environment. Thus, containers are one element of the environmentas a whole.

Figure 2: The relationship between Kubernetes and the software delivery toolchain

As with any technology platform, Kubernetes needs to be implemented in the right way, in order not tostore up problems for later. Specific challenges include:

• Complexity issues. Microservices applications can become complex and fragmented if architecturalconsiderations are not planned in advance.

• Communication flows. Organizations need to open channels of communication betweenoperations, development, and other stakeholders.

• Capacity bottlenecks. The architecture needs to be able to scale for future use without creatinginfrastructure or operational overheads.


https://gigaom.com/report/how-to-benefit-from-microservices/

• Infrastructure flexibility. Applications need to take into account the fact that infrastructure maychange, for example, to accommodate multi-cloud delivery.

• Process bottlenecks. Decision makers need to decide now on the processes and tools, anddetermine what can and should be left until later.

• Data integrity. Data sources, streams, and targets should be planned and configured to assurequality, accuracy, and trust.

• Security and compliance risks. Ensure the right pieces are in place to maximize effectivenesswhile minimizing risk.

• Platform evolution. Kubernetes itself is subject to change, as it is enhanced and updated by itscommunity.

These challenges can be exacerbated in the enterprise environment, as the specifics of scaling upmicroservices meet the well-understood but no less difficult issues of instigating change across theenterprise. We cover the strategy required in response, in the next section.


3. Setting a Strategy for Broader Kubernetes Deployment

So, how can decision makers define a strategy for broader Kubernetes deployment across theenterprise? We consider the following five stages:

1. Put the business first. Whatever the target architecture, a microservices-based infrastructurestrategy needs to be based on delivering business value. This requires looking at what thebusiness is trying to achieve, in terms of its broader business and digital transformation goals. Agood rule of thumb is to base this on actual budget allocations, as opposed to shareholderstatements. A second element is to engage business leaders (e.g. department heads) in strategysetting and review. Meanwhile, successful modern software programs require more than lip serviceto stakeholder involvement, i.e. “engaging with the business.” You will need to align yourmicroservices strategy with your ability to co-create software solutions with your users andcustomers.

2. Prioritize applications. Kubernetes offers an orchestration mechanism for highly distributed,scalable applications. It is a means, not an end in itself; Any application decision needs to be basedon response to a business need, with clear ROI. Kubernetes should not be a solution looking for aproblem, but a target for real applications. You should be able to reference a road map forapplication delivery, review, and prioritization, which will give you a tangible basis for a targetarchitecture.

3. Focus on architecture. The next element of the strategy is to define a Kubernetes-basedarchitecture that fits your priority application and service needs. The architecture should supportthe superset of service delivery parameters (consistency, availability, performance, and security)across applications. This will dictate the source, location, and usage models for Kubernetes; forexample, whether to depend on an external Kubernetes service from a cloud provider, to deployKubernetes in a private data center, or some combination of the two; how to allocate clusters todevelopment, staging, and production; and whether the resulting environment will be managedcentrally or as self-service instances.

4. Deliver terms of reference. Success will be based on a common understanding of how Kubernetesis to be managed and used by development teams and operational units across the organization.This means understanding and documenting roles and responsibilities, communications paths,processes, workflows, and escalation procedures, dependent on the selected architecture (e.g.centralized versus self-service development stacks). Management and governance do not have tobe bureaucratic. You can adopt a minimum-necessary approach; that is, what is the minimum ofcontrols and policy rules you need to have in place in order to succeed?

5. Standardize tooling across dev and ops. Scaling up Kubernetes is also an opportunity toconsolidate and standardize on the toolchains used across software development, delivery, andoperations. For development, bringing together both processes and tooling, GitOps is a good placeto start as a framework for deploying microservices from a git-based repository into the Kubernetesenvironment, as it brings git’s strengths to the DevOps workflow (such as audit logs, rollbacks, andsecurity), as well as assuring a level of consistency and standardization. For operations, cloud-native best practices that consider the management requirements of distributed applications, forexample, the need to observe performance and security, need to be balanced against more familiar


(ITIL-based) practices such as fault identification, diagnosis, and resolution.


4. Delivering the Platform

As an orchestration mechanism, the Kubernetes enterprise platform incorporates a number ofcomponent parts including:

◦ A declarative mechanism to enable configuration of a Kubernetes-based application, based onthe YAML markup language.

◦ A controller and scheduler to provide application deployment and management

◦ A registry to maintain run-time configuration and state information

These components enable the smooth deployment of microservices to Docker-based containers(within pods), to nodes in a specific cluster on a physical server (see figure 3).

Figure 3: Components of the Kubernetes microservices architecture

Technology choices exist to ensure that a flexible target is available for developers, and the mostappropriate choice will depend on both business and operational factors. In practical terms, manyorganizations are now setting their infrastructure strategy around a multi-cloud environment, so thetarget Kubernetes platform will need to take this into account. Meanwhile, the platform will need tointegrate with development pipelines and operational management tooling of data management andassuring visibility onto the resulting environment.


5. Organizational Perspectives

The success of scaling Kubernetes will be dictated by how well different stakeholder groups arebrought on board. Structures and processes, roles and responsibilities can be geared to maximize theefficiency and effectiveness of a Kubernetes-based microservices environment, but these need to besupported by a common base of understanding and communication between the following:

◦ Software producers. hile developers may already be looking to operate in a ‘continuous’ or‘cloud-native’ way, interfaces with other teams (such as security, testing, operations, and indeed,lines of business) can cause bottlenecks. Developers need to understand touchpoints withthese groups to avoid building up a “backlog of backlogs,” i.e., deliveries that cannot beimmediately deployed.

◦ Infrastructure operations. –This group needs to balance the needs of more agile deploymentonto a scalable Kubernetes-based platform, and still offer reporting and management, faultdiagnosis and resolution, compliance and security, capacity planning, data backup and so on,according to established (potentially ITIL based) processes.

◦ Platform teams. –Look after the open source-based software stacks required for microservicesdeployment, ensuring software packages are kept up to date and patched against securityvulnerabilities.

◦ Reliability architects. SREs and technical/systems architects oversee the software and servicesin development, ensuring service delivery criteria, such as performance at scale, availability,upgrades, Kubernetes platform security, and configuration updates.

◦ Management and liaison. Address questions of product-based software roadmaps,prioritization, capacity planning, resourcing, and financing.

Each group will have its own perspectives, drivers and pressures. For example, developer groups maybe looking to maximize the delivery of features, whereas management groups may be balancingresourcing needs with financial constraints.


6. Planning for Success

In summary, if done right, a Kubernetes implementation should be net-positive to the organization atevery stage. Below is a checklist of criteria for decision makers as they review their existing capabilitiesand prior use of Kubernetes:

◦ Create a baseline. Develop and agree on a foundation to build upon by understanding theneeds of each stakeholder group, current levels of Kubernetes knowledge and skills, successmeasures, and achievable targets.

◦ Pilot the initial build. Develop and pilot an architecture for Kubernetes-orchestratedmicroservices based on priority needs while developing operational skills, in parallel with testingand looking at what needs to be in place for the next stage.

◦ Scale up with a roadmap. To ensure you are always delivering on business needs, think from aproduct perspective rather than a software version perspective, across both applications andprocesses.

◦ Rationalize, refresh existing applications. Opportunities will exist to migrate existingapplications and services into a microservices architecture. At the same time, considerKubernetes adoption as an opportunity to assess your existing application estate and look forlow-hanging fruit for migration.


7. Key Takeaways

While Kubernetes is still relatively new to many enterprise organizations, it looks set to become a defacto mechanism due to the general flexibility of the microservices approach, and the resulting needfor a scalable orchestration platform. At this stage, organizations need not fret about being behind thecurve. Now is a good moment to acknowledge the momentum behind microservices and Kubernetes,to build them into a technology delivery strategy, and to build valuable skills and experience.

For enterprises looking to adopt Kubernetes, the best strategy is to see beyond the pilot and look athow to scale up, and what pieces need to be in place to avoid future discomfort. From a businessperspective, these models unlock the potential of a flexible, scalable deployment target that respondsto the drivers of digital transformation. In terms of day-to-day activity meanwhile, the approach is aboutenabling collaboration across stakeholder groups, as much as any technical advantage. By thinkingbeyond single implementations and adopting a strategy that suits the needs of the organization as awhole, you can start reaping the rewards of Kubernetes now, while preparing for the future.


8. About Jon Collins

Jon CollinsJon Collins has advised the world’s largest technologycompanies in product and go to market strategy, acted as anagile software consultant to a variety of Enterpriseorganizations, advised government departments on ITsecurity and network management, led the development of amobile healthcare app and successfully managed a rapidlyexpanding Enterprise IT environment. Jon is frequently calledupon to offer direct and practical advice to support IT anddigital transformation strategy has served on the editorialboard for the BearingPoint Institute thought leadershipprogram and is currently a columnist for IDG Connect.

Jon wrote the British Computer Society’s handbook for security architects and co-authored TheTechnology Garden, a book offering CIOs clear advice on the six principles of sustainable IT delivery.He has written innumerable papers and guides about getting the most out of technology and is anaccomplished speaker, facilitator, and presenter.


https://gigaom.com/analyst/collins-jon/

9. About GigaOm

GigaOm provides technical, operational, and business advice for IT’s strategic digital enterprise andbusiness initiatives. Enterprise business leaders, CIOs, and technology organizations partner withGigaOm for practical, actionable, strategic, and visionary advice for modernizing and transforming theirbusiness. GigaOm’s advice empowers enterprises to successfully compete in an increasinglycomplicated business atmosphere that requires a solid understanding of constantly changing customerdemands.

GigaOm works directly with enterprises both inside and outside of the IT organization to apply provenresearch and methodologies designed to avoid pitfalls and roadblocks while balancing risk andinnovation. Research methodologies include but are not limited to adoption and benchmarkingsurveys, use cases, interviews, ROI/TCO, market landscapes, strategic trends, and technicalbenchmarks. Our analysts possess 20+ years of experience advising a spectrum of clients from earlyadopters to mainstream enterprises.

GigaOm’s perspective is that of the unbiased enterprise practitioner. Through this perspective, GigaOmconnects with engaged and loyal subscribers on a deep and meaningful level.


10. Copyright

© Knowingly, Inc. 2019. "Scaling Up Enterprise Kubernetes" is a trademark of Knowingly, Inc.. Forpermission to reproduce this report, please contact [email protected].


https://www.knowingly.com/

https://www.knowingly.com/

mailto:[email protected]

moving microservices from pilot to platform€¦ · •setting the strategy-outlining a...

Documents