5 strategies for enterprise cloud infrastructure success

1© 2018 Rogue Wave Software, Inc. All Rights Reserved.
Taking control of your open source stack
Episode 1:
5 strategies for enterprise
cloud infrastructure success

Phil Morris
Open source software field CTO
Rogue Wave Software

Justin Reock
Senior director, support & professional services
Rogue Wave Software

Click here to
watch the full on-demand webinar

• You’re already aware of the benefits that open source
brings to your business
• Faster time to market, lower (or zero) license costs, and
freedom to deploy in any direction improves your
competitive edge
• When combined with the organizational cost savings of
cloud deployment, you can’t go wrong!
• Or can you?
Getting your head in the clouds…

• As always, developing the right strategies around your
cloud deployment of OSS can make or break your
experience
• We’ll discuss five separate strategies for maximizing the
benefit of using open source in the cloud
• While by no means an exhaustive list, these are some
of the more important things to consider when deploying
your open source in a cloud environment

Automation &
orchestration
Choosing a
support model
Avoiding vendor
lock-in
Curating the
best software
Figuring out
where to start

– The creation of processes to manage individual tasks
Properly defining these terms
Automation
Orchestration
– Suggests the coordination of those automated tasks to
build business workflow

• Both automation and orchestration are necessary to
squeeze the most benefit out of deploying open source in the
cloud
• A benefit to cloud patterns involves obviating involvement
with infrastructure substrate
• This frees us from the kind of manual work which would add
significant time and overhead to systems at enterprise scale
• And, it allows for trivial repeatability of configuration and
deployment

• Elastic scale is often a goal of moving applications into
the cloud
• When new instances are added, they should be added in
as turnkey a way as possible
• Any amount of human involvement in spinning up these
instances will slow the deployment and is prone to
error
• This is completely counter to the purpose of cloud scale
deployment

• While many solutions have emerged, Ansible is the leading product
• Ansible’s declarative configuration approach and agentless
controller make it ideal for cloud automation and orchestration
• Although technologies such as Puppet and Chef have been around
longer, Ansible’s functionality has grown significantly through its
vast module library
• And Ansible plugs nicely into all modern cloud compute
frameworks, whether virtualized or in a container environment such
as Kubernetes
How do I get going?

• Ansible’s community edition is completely free and open
source
• Its functionality is further extended by the open source
AWX project
• AWX, the open source edition of the commercial Ansible
Tower solution, allows for enterprise-class
management of Ansible configuration
Where should I start?

• Ansible’s playbook driven configuration is meant to be
easy to understand and powerful
• Getting started with Ansible is as easy as installing the
Ansible controller engine and running some playbooks
• A huge number of tasks can be performed using Ansible’s
base configuration and it’s many modules
Where should I start?

• When you take your systems cloud-scale, the true
benefits are only realized when proper automation and
orchestration are in place
• Though the terms have different definitions, they are very
closely related
• An excellent solution for achieving strong automation and
orchestration is the open source Ansible solution and its
optional AWX framework
Summing it up

• Modern software, especially open source software, is a fluid
and ever-evolving space
• As a result of this dynamism, new and better solutions to
common business problems emerge rapidly
• But proprietary solutions are often made “sticky” by
design
• Refactoring or migrating from these solutions can involve
significant effort
The importance of vendor freedom

• Businesses should always be considering ways to improve
efficiency and reduce cost
• So, ”locking-in” to a particular solution today almost always
leads to more work in the future, when a new solution is
desired
• More flexible frameworks are desired in a cloud scale
solution, so be careful to choose community editions of
projects where possible
Minimizing technical debt

• Apart from the freedom and flexibility that comes with choosing a community
edition, there’s also license cost to consider
• Cloud-scale implementations tend to get larger so, license costs tend to
increase as well
• Vendor audits can be expensive and time consuming – a major financial
services company recently completed a 500 hour audit spanning 2 years
• By choosing a community edition, you eliminate a major cost center and
reduce impediments to growth
• Sometimes just acquiring the license itself requires procurement overhead
which can slow scaling initiatives considerably
Minimizing raw cost

Here’s what we’re doing…
We encourage our customers to use the
community editions of their projects of choice
Community ownership ensures broad oversight and
diverse opinions
As you’ll see in our section detailing a choice in support models, you
can balance support with the benefits of a community edition

• Note that this is not a universal statement
• There are ”enterprise editions” of software which do provide tangible
benefits beyond the free editions
• Be sure that you really have a valid use case for the extended functionality
• Remember that vendor portfolios can become large and difficult to
manage, making “war room” scenarios cumbersome
• In many cases, that additional functionality can be found in a different
solution or even grown at home
• That up-front investment can save in organizational and license cost in
the future as your implementation grows
Avoid where possible

• Open source in the cloud is all about freedom
• Freedom to grow and expand without huge impact from
infrastructure and license cost
• So in many ways, a proprietary edition of a piece of software
goes against the grain
• Where possible, choose the community edition of a product
• You can still balance that with reliability and availability by
choosing the right support model
Summing it up

Click here to

We’ll look at a few specific ones here…
How do we determine best-in-class?
We look at a number of factors when determining whether a project can
be considered viable for production use
Characteristics of the community, availability of human resources, and
project activity are all major factors

• One very important set of factors are the resources available to
you:
– Is there a project Wiki / Knowledge Base / FAQ?
– Is there an active mailing list for both users and devs?
– Is training and support available, preferably commercial
training and support?
– Is the source code readily available?
– Are binary builds available, where applicable for an adequate
set of architectures?
Resources

• The size and strength of the community factor in as well:
– Does the community have a defined structure?
– How many developers and committers are involved?
– Is there a public bug tracker?
– Is there a defined release schedule, or at least a regular
release cadence?
– How quickly does the community respond to critical
security issues?
Community factors

• Although difficult to determine accurate numbers, several
vectors are available:
– Turnout at sponsored or related conferences
– Prevalence of blogs/white papers written by third-parties
– Availability of third-party training resources such as online
tutorials
– Industry use cases from large enterprises
Adoption

• There are several ways in which we can judge the quality of a project,
but some important ones include:
– Longevity of the project
– Do we see an unreasonable amount of bug activity after major
releases?
– Is semantic versioning part of the community practice?
– Does the project use a CI/CD pipeline with automated unit testing for
deployment?
– Are developers asked to write unit test cases as part of pull request
acceptance?
Project quality

• It’s hard to know for certain what open source projects are destined for
success or failure
• Widespread adoption of a project ensures multiple entities driving
expectations of maturity and quality
• The size and activity of a community can offer insight into that project’s
likelihood for long term success
• And the availability of resources to help you adopt the project is a
compelling factor as well
• A solid cloud-scale OSS implementation begins by choosing the best
software available for your use case
Summing it up

Why do we even need support?

• Over 90% of businesses are utilizing some sort of open source in their critical
infrastructure
• Like any other form of software, there is a cost of ownership assumed when
maintaining open source software in production, or migrating to such a solution
• Although the license cost savings gained by using free software are clear, the risk of
running software without warranty or maintainer liability is significant
• Businesses can benefit from the competitive edge gained by adopting OSS
solutions by mitigating that risk
• Businesses who successfully make the shift to OSS solutions do so in part by
creating and executing a strategic plan for supporting this software which they
did not write, and do not own
Why do we need support?

Types of support
Commercial
support
Self support
Community
support

Self-support
• Low direct incremental cost
• Complete control over support
resources
• Opportunity for internal team-
building, cultivating code owners
• Inevitable where a private fork of
the code is necessary
• Impossible w/o particular
expertise
• Higher risk (due to
dependencies on individuals)
• More internal management
overhead
• Usually higher actual TCO (due
to low economy of scale)
Pros Cons

Community support
• Extremely low cost
• Low commercial and legal barriers to
entry
• Access to code authors, experienced
users
• Potential for greater influence over
project direction, leadership
• No SLAs – informal relationship
• Community priorities may not match
your organization’s
• Indeterminate responsiveness
 Bug reports ignored
 Patch acceptance
• Social network “exposure” and
acculturation requirement
Pros Cons

Commercial support
• Redundancy in skillsets and available
resources
• Guaranteed SLAs governing response and
resolution time
• Access to niche expertise and thought
leadership
• Proactive guidance such as patching and
vulnerability awareness
• Interaction with experts who have vetted
the products in dozens of environments for
multiple business use cases
• Adds additional cost to existing TCO of
maintaining and/or migrating to OSS
infrastructure
• “Enterprise” solutions are often locked-in and
proprietary
• Approval for vendor contracts generally
means negotiation with procurement/legal,
outside the boundaries of most developer
domains
• Dependence on third-party support can
sometimes cause accidental cultural
separation from project communities
Pros Cons

Mixing support models
• By combining models, you can achieve “best of all worlds”
• Commercial support complements self-or community support
• Mix of models usually evolves over time
– Organizations often start with community and/or commercial
support and develop internal skill sets over time
– Can be difficult to meet product schedules with self-owned or
community resources – need SLA from commercial support entities
• Commercial support companies offer various models
– Per-incident, 2nd or 3rd tier support plans, etc.

Summing it up
Business who gain the most benefit from open source in the cloud
while minimizing risk do so by adopting and executing an appropriate
support model
The best models involve a combination of solid self-support,
interaction with communities, and a reliable commercial support vendor
By leveraging the best parts of all three models, businesses can realize a
robust cloud-scale enterprise built completely on free software

• Hopefully this session has helped you to start
thinking of ways to move your open source into
the cloud
• You’ve got an idea of the potential pitfalls, and you’re
ready to start cutting costs and improving reliability
• So, what now?
So many options…

• Depending on your specific workloads, you may want to run your
processes in any of three commonly accepted cloud models
– Public: In which your workloads run in a third-party hosted
cloud environment such as AWS
– Private: Where you are using a proprietary infrastructure
running on-premises in your own datacenter
– Hybrid: Where resources can be shared between a private
and third party infrastructure, and orchestration exists to
coordinate workloads between both environments
Public, private, or hybrid?

• With a public cloud, all of your infrastructure needs become the responsibility of
a third party
• This can help reduce your organizational costs dramatically
• However, you ultimately have less control over the more granular details of the
infrastructure
• And, you may find yourself locked-in to the proprietary services available on that
cloud
• If you are working with very sensitive and/or proprietary data, you are placing that
data in the hands of a third party
• Vulnerabilities like Spectre and Meltdown underscore some of the possible
problems with such an infrastructure
Public

• In this model, you choose your infrastructure stack and run your
workloads in your own datacenter
• Solutions like OpenStack, oVirt, and/or Kubernetes can help get this kind of
infrastructure up and operation quickly
– However OpenStack may be too heavy a solution for a lot of users
– A lighter stack consisting of orchestration tools and a control plane
like Kubernetes may be more desirable
• Although this solution carries more overhead than a public cloud, and has
a resource ceiling, it is ideal for maintaining granular control over
infrastructure and ensures data isolation
Private

• In this model, certain workloads can move to either a public or private
cloud environment using orchestration
• The integration between private and public layers is ideally seamless
• This is great for an infrastructure that may need to “burst” to a public cloud
during periods of load
• Or where a mix of sensitive and non-sensitive workloads are required
• Most modern enterprises are taking advantage of this pattern, as with
the right orchestration it represents the best of both worlds
• In this pattern, the workloads shouldn’t care where they are running, and
orchestration rules should govern the environments in which they live
Hybrid

• For public cloud, choose a vendor with support SLAs that match your
business requirements, and with a pricing model that works within your
infrastructure budget
• Since you’ll be deploying your own community open source, existing
services such as Amazon’s RDS may not be important
• Treat this vetting process as you would with any other vendor, balancing
metered cost with functionality
• Be sure to understand specific needs around PII/GDPR sensitivity, network
responsiveness, etc., and ensure your vendor can meet these requirements
• And remember to avoid lock-in where possible
Choosing a public cloud vendor

• This is where understanding your workload needs becomes incredibly
important
• For distributed, lightweight and/or microservice workloads, a container-
based solution is ideal
• A proven product like Kubernetes and its surrounding ecosystem is the
most mature and robust solution currently available
• If you want a full private cloud experience which accounts for multi-
tenancy, software networking, etc., OpenStack may be ideal for you
• Just note that most people do not use all the functionality that is
included with OpenStack
Choosing a private cloud stack

• If you really want strict controls over your application stack and
cloud fabric, a private or hybrid curated stack may be the way to go
• A solution like our OpenLogic stacks allows you to take advantage
of cloud orchestration while only utilizing components you need
for your business
• Our orchestration model allows for flexible modularity in
choosing current and future components
• And the application environment has been hand picked by our
leading industry experts
Curated for flexibility

• Getting started with cloud enablement of your open source begins
by understanding your workload needs
• Knowing the difference between private, public, and hybrid cloud
architecture can inform these decisions
• Solutions like OpenStack can be ideal for cloud-scale infrastructure
running on-prem or in a hybrid mode
• And for those who prefer to pick and choose their components, a
curated stack like the OpenLogic stacks can give you an ideal
environment for running your code
Summing it up

Click here to

• We’ve discussed some of the most important strategies for maximizing
the benefit of running open source in the cloud
• Automation and orchestration are essential, and a solution like Ansible
can automate your business rapidly
• Avoiding vendor lock-in will ensure future cost control, flexibility, and
success
• Choosing the right support model will help minimize your risk
• And knowing how to curate the best in class open source will further
minimize this risk and allow proper functionality
• With those considerations out of the way, you can choose a cloud model
and get going!
• And don’t forget, we’re here to help!

Episode 2: How to choose the right open source stack
August 9th – 1 p.m. EST
Host: Rod Cope
ZendCon and OpenEnterprise (zendcon.com)
October 15 – 17, Las Vegas
Justin presenting two talks detailing Apache ActiveMQ and Apache Camel
All Things Open (allthingsopen.org)
October 21 – 23, Raleigh, NC
Justin presenting “Open source applied – Real world use cases”

Request your 15 minute cloud/container
readiness assessment at
FREE YOUR MIND
RELY ON OURS
roguewave.com/opensource-15

5 strategies for enterprise cloud infrastructure success

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 5 strategies for enterprise cloud infrastructure success

Similar a 5 strategies for enterprise cloud infrastructure success (20)

Más de Rogue Wave Software

Más de Rogue Wave Software (20)

Último

Último (20)

5 strategies for enterprise cloud infrastructure success

Notas del editor