SUSECON Digital 22 Scale your CICD setup for Cloud Native microservices via InnerSource.pptx

Copyright© SUSE LLC
Scale your CICD
setup for Cloud
Native
microservices via
InnerSource
SESSION CODE (BOV-1223)
By
Turja Narayan

Turja Narayan
Chaudhuri
Assistant Director, EY GDS
turjachaudhuri@gmail.com
+91 78905885267
Introducing the speaker
2
2
— Currently , I am working as an
Assistant Director, Cloud Practice at
EY (Ernst & Young).
— Before that I led the CCOE ( Cloud
Centre Of Excellence) Team at
Accenture.
— I Have around 10+ years of IT
experience , working on Public Cloud
technologies since 2017.

Agenda: 1. Section I - Discuss challenges in scaling microservice
CICD adoption.
2. Section II – How to achieve standardization in cloud-
native application delivery.
3. Section III – How InnerSource can help in enhancing
adoption across the enterprise.
4. Section IV – Conclusion : Where do we go on from
here?
3

Discuss the current state and
potential issues in adopting
a streamlined approach for
cloud-native microservice
adoption.
Section I - Discuss
challenges in scaling
microservice CICD
adoption.
4

— Enterprises are under more
pressure to innovate faster
and increase product velocity.
— It is agreed by the industry
thought leaders that
enterprises that are not able
to effectively support
microservices will be less
able to compete in the
future.
— Enterprises who have
adopted microservices are
more likely to perform well
against metrics like
development efficiency, the
ability to use new platforms,
collaboration across teams
and sharing of services across
applications.
Microservices have taken over enterprise IT by storm.
As per O’Reilly Microservice adoption report, 77% of respondents have adopted microservices.
5

— Microservices - also known as the microservice architecture - is an
architectural style that structures an application as a collection of
services that are
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
— The microservice architecture enables the rapid, frequent and
reliable delivery of large, complex applications. It also enables an
organization to evolve its technology stack.
Let us try to understand, at a high-level what is a microservice.
Ok, but what do we mean by a “microservice” ?
6

— Concept of building and running applications to
take advantage of the distributed computing
offered by the cloud delivery model.
— Cloud native apps are designed and built to
exploit the scale, elasticity, resiliency, and
flexibility the cloud provides.
Cloud is where you compute ,Cloud-native is how you compute.
But , what is “cloud-native” ?
7

Most digital transformation initiatives involve an application
modernization journey from monolith to microservices
From monolith to microservices
8

Microservices are a great fit for cloud-native architectures as they
support the cloud-native principles
Cloud-native embraces microservices
9
— Microservices are the core of cloud native
application architecture, and they have
become a key tool for companies that are
making the move to the cloud.
— Microservices arrange an application into
multiple, independent services, each of
which serves a specific function.
— Cloud native microservices communicate with
each other via APIs and use event-driven
architecture, which serves to enhance the
overall performance of each application

Many issues start appearing when an enterprise decides to adopt
microservices
However, at scale, microservice adoption is challenging
10
— In most enterprises , every team has their own way of creating and
deploying microservice based architectures onto a compute platform
like Kubernetes; there is no standardization.
— This effectively leads to multiple ways of doing the same thing , and
in many cases the best practices/security/compliance guidelines are
ignored.
— No standard set of guidelines are enforced, and duplication is
encouraged.
— Every new team has to setup the environment and CICD pipelines from
scratch effectively delaying the deployment to production.

Where does DevOps fit in the Cloud-native paradigm
11
— DevOps is a set of practices that combines
software development and IT operations.
— You cannot achieve a mature or
streamlined cloud-native application
delivery lifecycle without having a strong
DevOps practice to support the process.
— Effective implementation of cloud-native
DevOps helps businesses to market fresh
technologies more rapidly, speeding up
their digital transformation.
DevOps is the primary cornerstone on which effective cloud-native application deployment and delivery is
based on.

In order to promote
microservice architectures at
scale, we need to adopt a
standardized, opinionated
application delivery
lifecycle supported by the
enterprise toolkits.
Section II – How
to achieve
standardization
in cloud-native
application
delivery
12

Why do we need standardization?
13
Standard practices and patterns, as opposed to working in silos need to be adopted to promote a new
technology paradigm across an enterprise.
— In order to ensure that more teams across an
enterprise adopt cloud-native microservice
architectural patterns and practices, an enterprise
needs to provide a standard way of creating,
deploying and consuming microservices.
— An enterprise needs to provide standard
templates, scripts, architectural guidance and
documentation that a team can adopt in order to
quickly build their custom microservice based
architecture on top.

— Architecture
– Generic
guidance that
provides a
starting point.
– Teams can tailor
as per their
needs, while
being aligned to
the basic
principles.
— Deployment
Pipelines
– Standard
DevOps platform
selection.
– Standard CI/CD
pipelines
— Programming
Practices
– Standard
programming
languages.
– Standard module
selection, coding
styles,
comments, and
so on
— Practices and
Patterns
– Standard agile
practices
including tools,
taxonomy
– Standard SDLC
patterns, support
modules, project
management
lifecycle
An enterprise needs to have a concrete plan while implementing or enforcing
standardization across all verticals.
But what do we standardize?
14

The main operation unit of a DevOps process is the CI/CD pipeline
enforced by a consistent toolchain.
Let’s take an example – CICD pipelines
15
— A CI/CD pipeline is a series of steps
that must be performed in order to
deliver a new version of software.
— Although it is possible to manually
execute each of the steps of a CI/CD
pipeline, the true value of CI/CD
pipelines is realized through
automation.

Pipeline sprawl in an enterprise
16
Too many diverse/unique pipelines within an enterprise leads to pipeline sprawl.
— As an enterprise grows, the same CICD pipelines that
offer many benefits starts growing in numbers.
— Each team has their own way of
packaging/building/deploying artifacts, even
though essentially they are doing the same thing.
— This essentially results in 100’s or 1000’s of pipelines,
which is called ‘Pipeline Sprawl’.
— Pipeline sprawl makes it difficult for DevOps teams to
identify and reuse common execution patterns which
diminishes their ability to efficiently ship new code.

How to standardize pipelines and counter sprawl
17
Create reference pipelines and eliminate pipeline sprawl
— Establish a DevOps Dojo Team that is in-charge of
creating, maintaining, updating and governing a set of
pipelines that can be consumed by different teams within
the enterprise.
— These pipelines, also called ‘Reference pipelines’ can be
easily consumed by teams, and as a result gives them an
easy way to create a CICD pipeline from scratch rather than
creating it from scratch.
— At the end, an enterprise only has a limited number of
deployment patterns, so the idea is to create a reference
pipeline for each of those standard patterns, enforcing
reuse and standardization.

What is DevOps Dojo ?
18
Too many diverse/unique pipelines within an enterprise leads to pipeline sprawl.
— A DevOps Dojo is a place where DevOps team members
go for hands-on training.
— In software development and operations management,
DevOps Dojos provide learners with an immersive
environment where team members can gain practical work
experience without having to worry about introducing errors
into the production environment.
— A DevOps Dojo team is usually made up of the learning
product team, product managers, Agile coaches and
engineers.

Reference pipelines – an example implementation
19

Microservice deployment via Reference pipeline
20

A central team cannot scale
to meet the myriad demands of
an enterprise unless everyone
participates and contributes
Section III –
How InnerSource
can help in
enhancing
adoption across
the enterprise
21

What is InnerSource?
22
Traditional silo-based development models do not scale, and as such enterprises need to adopt an
InnerSource methodology to move forward.
— InnerSource is a development methodology where
engineers build proprietary software using best
practices from large-scale open source projects.
— InnerSource code helps your team discover, customize,
and reuse existing internal projects. They can also
establish and build on a shared set of documented
processes to optimize the way your company deploys and
uses software. This can lead to lower cost, greater flexibility,
and an end to vendor lock-in.

Why do we need InnerSource?
23
InnerSource helps unlock the latent potential that is present within an enterprise’s workforce and leads to
better collaboration and code sharing at scale, across teams.
— In an enterprise, any central governance unit, be it DevOps Dojo, or
an Architecture governance board, cannot meet all the demands
from different development teams.
— No matter how many reference pipelines/YAML templates are
prepared as a standard implementation, there will be special/edge-
cases where development teams will ask for use-cases which are
not covered as part of the current offering.
— In those instances, it makes sense to have a process by which
xSL development teams can contribute, collaborate and
submit enhancements to the current offerings.

An InnerSource development workflow or lifecycle is directed at
enhancing productivity and velocity by tapping the enterprise
workforce.
Typical InnerSource developer workflow
24

To scale beyond the limitations of a central team, a
microservice
How InnerSource can help in microservice adoption
25
— It is impossible for a central governance unit/a
DevOps Dojo team to be able to cater to the wide
variety of business use-cases put forward by the
different development teams.
— They might create a few reference pipelines for
the most-common use case, but not for all possible
options.
— A developer can then download the reference
pipeline YAML, modify it as per their
requirements, which meets their business use-case.
— When done, the developer will push the changes to
the main repo, making it usable by all the
developers in the enterprise.

— Strategy
– Provides a
scalable
approach within
the constraints of
the host team.
– Enables teams to
be able to deliver
incremental
business value
without
increasing
headcount.
— Force multiplier
– Allows host team
to act temporarily
larger than its
actual size.
– Allows
engineering
teams to
organically flow
where the
organization
needs it at a
given time.
— Higher Job
Satisfaction
– Interactions
between trusted
committers and
contributors
enable growth
and education.
– Learning and
alignment breaks
down traditional
silos.
— Increase adoption
of new toolchains
– Provides a way
to rapidly skill an
enterprise in a
new technology.
– Increases
interest and
provides a
compound effect
by involving new
developers.
An enterprise needs to have a concrete plan while implementing or enforcing
standardization across all verticals.
Advantages of advocating an InnerSource based approach?
26

A brief summary of our
learnings and a positive,
collaborative way to move
forward.
Section IV –
Conclusion :
Where do we go
on from here?
27

Lessons to act, and way to move forward to enhance
productivity.
What is the key learning from all of this.
28
— Developer experience is the key. Any adoption
initiative can only succeed if developer buy-in is
ensured from early stages.
— Microservices are great as an architectural
pattern but there is a steep learning curve. To
ensure proper adoption, we need to provide
developers a template or framework for rapid
deployment and delivery, rather than having to
create everything from scratch.
— Reference CICD pipelines along with overall
architectural guidance can go a long way, if
combined with InnerSource and letting all
developers contribute in building more assets for
the teams.

A summary of actions we need to take to incentivize
microservice adoption
Microservice Adoption Journey
29

How to unlock the immense possibilities that the future holds
for us.
What is in the future, where do we go from here?
30
— Self-service via IT Catalog to provision
standard microservice architectures via
templates.
— Create a cross-functional architecture
governance board that is in-charge of the
standards and enforcement with compliance
or patterns.
— Implement InnerSource patterns at scale
across the enterprise, not only for
microservice adoption but for all other IT
aspects as well.

© SUSE LLC. All Rights Reserved. SUSE and the SUSE
logo are registered trademarks of SUSE LLC in the United
States and other countries. All third-party trademarks are
the property of their respective owners.
General Disclaimer: This document is not to be construed as a
promise by any participating company to develop, deliver, or market
a product. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing
decisions. SUSE makes no representations or warranties with
respect to the contents of this document, and specifically disclaims
any express or implied warranties of merchantability or fitness for
any particular purpose. The development, release, and timing of
features or functionality described for SUSE products remains at the
sole discretion of SUSE. Further, SUSE reserves the right to revise
this document and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or
changes. All SUSE marks referenced in this presentation are
trademarks or registered trademarks of SUSE, LLC, Inc. in the
United States and other countries. All third-party trademarks are
the property of their respective owners.
For more information, contact SUSE at:
+1 800 796 3700 (U.S./Canada)
+49 (0)911-740 53-0 (Worldwide)
Maxfeldstrasse 5
90409 Nuremberg
www.suse.com
Thank you

SUSECON Digital 22 Scale your CICD setup for Cloud Native microservices via InnerSource.pptx

Recommended

Recommended

More Related Content

Similar to SUSECON Digital 22 Scale your CICD setup for Cloud Native microservices via InnerSource.pptx

Similar to SUSECON Digital 22 Scale your CICD setup for Cloud Native microservices via InnerSource.pptx (20)

More from Turja Narayan Chaudhuri

More from Turja Narayan Chaudhuri (10)

Recently uploaded

Recently uploaded (20)

SUSECON Digital 22 Scale your CICD setup for Cloud Native microservices via InnerSource.pptx