Implementing Cloud-based DevOps for Distributed Agile Projects

1© Copyright 2012 Coveros, Inc.. All rights reserved.
Implementing Cloud-based
DevOps for Distributed Agile
Projects
Thomas Stiehm, CTO
tom.stiehm@coveros.com

 Coveros helps organizations accelerate the delivery of
business value through secure, reliable software.
About Coveros

Cloud-based
 Cloud Computing - In its essence, Cloud
Computing is a massive distributed
computing model consisting of three tiers:
infrastructure, platform and services, and is
about using swarms of computers to deliver
unprecedented computing power to people
and organizations across the globe. Cloud
computing isn't a new technology nor a new
architecture... it's a new delivery model.1
1. http://www.mkpress.com/CloudReading

DevOps
 DevOps – A combination of Development
and Operations, it is a software development
method that stresses communication,
collaboration and integration between
software developers and Information
Technology (IT) professionals. DevOps is a
response to the interdependence of software
development and IT operations. It aims to
help an organization rapidly produce
software products and services.1
1. http://en.wikipedia.org/wiki/DevOps

Distributed Agile Projects
 Distributed Agile, as the name implies, is a
model in which projects execute an Agile
Methodology with teams that are
distributed across multiple geographies.1
1. . Distributed Agile, DH2A: The Proven Agile Software Development Approach and Toolkit for Geographically Dispersed Teams By: Upadrista Venkatesh

Cloud Computing Services
 Cloud Services Models:
–Software-as-a-Service (SaaS) vendors
that offer web applications, often with the
ability to customize and extend the
applications, ex. SalesForce.com
–Platform-as-a-Service (PaaS) vendors
that give developers the tools to build and
host using specific frameworks or
services, ex. Google Apps Engine
–Infrastructure-as-a-Service (IaaS)
vendors that offer access to raw storage
and computing resources, ex. Amazon
EC2

Features of Cloud Services
 Cloud Provisioning
 Dynamic Computing Infrastructure
 Self-Service, Self-Managed Platforms
 Programmatic Control of Server Resources
 Internet Access
 Geographic Distribution

Lessons Learned: The Project
 The technology parts are challenging
 The people parts are hard, often really hard
 Automate everything as early as possible
 Automation is software, treat it like the
application code –
– version
– review
– test
 Test everything, including your automation
 As you learn error and failure conditions,
automate dealing with them

Lessons Learned: The Vendor
 The right cloud vendor can make or break
you. Pick one that meets your needs, skip
any that don’t provide real cloud services.
 There is no perfect cloud platform, they all
have problems.
 If you pick a cloud provider that expects
things to be done their way, do it their way.
 If you pick a cloud provider that offers extra
services that induce lock-in, consider using
their extra services but think about it a lot. It
could work better than rolling your own.

Things to Expect
 Expect to do a lot of learning, teaching,
hand holding and pushing for new practices
 Expect to explain things multiple times:
issues, processes, practices, and
priorities at multiple levels: developers,
architects, testers, BAs, Project Managers,
Product Managers, Directors, VPs, the client,
and end users
 Expect confusion, rejection and clinging
to old practices
 Expect to do a lot of expectation setting
and resetting

Things to Expect
 Expect to make ultimatums and to get
strong pushback to those ultimatums
 Expect to fail the first time, with almost
everything you put in place
 Expect everything to take longer than you
planned
 Expect the expectation of immediate
results and payoffs, work your way through
them
 Expect your detractors to take credit when
things, in the end, succeed

How to Best Leverage the Cloud
 Understand your system, application and
organizational requirements
 Pick a Service Model
–SaaS
–IaaS
–PaaS
 Pick a Vendor that suits your requirements,
service model and budget
 Train your team on the vendors technology
and service model

Live in the Cloud
 Use Cloud-based service to
communications:
–Text (IM and Email)
–Voice
–Video
–Collaboration
–Source Code Management
–Code Review
–Project Management Software
 Using Cloud services helps to make people
around the country or globe equal members
of the team and reduces location bias

Living in the Cloud Example
 Requirements gathering using Cloud
resources such as Google Docs and Sites
 Task Management in the Cloud using Trello
 Project Management in the Cloud using
VersionOne
 Development in the Cloud using EC2
 Development Resources in the Cloud using
GitHub
 Testing in the Cloud using EC2
 Deployment and OPS in the Cloud using
EC2

Enabling Distributed Teams
 Use Cloud-based technologies to avoid
second class team syndrome
 Face to Face team building
–In person is best
–Video is better than nothing
–If your locations don’t “know” each other,
they won’t trust each other
–Phone calls aren’t enough
 Make sure that all locations have equal
opportunities for
–Advancement
–Interesting Work

What are the Advantages?
 Ability to focus on your core value
 Flexibility
 Time to market
 Speed of development
 Less up front cost
 Proven platforms
 Scalability or at least scalability patterns
 No hardware infrastructure to manage
 Geographic distribution
 Cheaper?

Cloud Provisioning
 Most people think of dynamic production
scaling when they think of Cloud provisioning
 But it also means:
–Full setup and tear down of test
environments
–Creation and disposal of development and
test environments based on need
–Scaling development and test
environments to fit the task, so if you want
to do performance testing on a duplicate
of your production environment, you can,
without having those resources in-house

Programmatic Control
 Programmatic control of self-service APIs
allows your team to fully automate setting
up and tearing down resources for:
–Dynamic scaling of production resources
–On-demand creation of development and
test resources, sized to fit the immediate
needs
–Fully automating the development, test,
and deployment life cycle
 Automation is not magic. You have to work
at it, maintain it, and manage configuration
data.

Self-Service API
 Automated everything
–Development Setup
–Test Setup
–Running Tests
–Populating Application Data/Test Data
–Builds
–Deployment
–Monitoring/Scaling
–Reporting
 Be able to rebuild your entire environment,
including your development, test tools and
servers automatically

Cloud vs. Traditional Development
 Vendor lock-in - Your application code will be
tied to the vendor's service offering, you will
be integrating their API and Services into
your code
 You are dependent on their development
and testing, resources and practices
 You don’t have the same level of control,
with SaaS and PaaS you are plugging your
software extension into the vendor’s system
 To get the advantages of cloud platforms you
must work within their constraints, using their
tools or your tools their way

Trade-Offs
 Loss of control: You no longer control the
infrastructure. It can go down or change and
you have to deal with it and live with it.
 The cloud vendor has a different set of
priorities than you.
 You don’t have to worry about infrastructure.
 SaaS gets you started very quickly, but it
limits how you can grow.
 PaaS simplifies your choices but locks you in
 IaaS can be like a CoLo arrangement with
more control and all of the responsibility.

Derailments
 Picking the wrong vendor
 Picking the wrong service model
 No automation: development, deployment
test or infrastructure
 Physical data-center operator mentality
 No access VM consoles or VM API
 Staff that is adamantly against change,
management that doesn’t support change
 Application requirements that don’t fit within
the vendor’s framework

How to Begin
 Create a plan, short term, near term, long
term. You are going to get it wrong, keep
adjusting and resetting expectations.
 Focus on priorities.
 Base priorities on business values,
however you define that. If you don’t show
value, you will fail in the long run.
 Start simple and get more sophisticated
as you go. You are going to have to refactor
your work/process/practices anyway as you
don’t know what you are doing at first, so
rework/refactoring is unavoidable.

How to Begin
 Work in small, quick steps, adjust your
strategy and tactics around things that
work.
 Fix pain points. Focus on fixing the pain
points of the people that have the most to
gain, prove the value to them and their direct
management.
 Get key stakeholders and influencers on
your side. Show them how life will be better
for them doing things your way.
 Some people will reject the new way of doing
things. Route around them and eventually
the organization will leave them behind.

Reasons not to use the Cloud
 You have a stable Application with little new
requirements
 You have an infrastructure that meets your
needs
 You need to have complete control over your
entire environment and have little risk
tolerance
 You have to budget exact resources, and
allowing for flexibility and dynamic computing
isn’t allowed
 There isn’t any benefit to changing your
process and practices, for now

Thank You

Implementing Cloud-based DevOps for Distributed Agile Projects

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Destaque

Destaque (8)

Semelhante a Implementing Cloud-based DevOps for Distributed Agile Projects

Semelhante a Implementing Cloud-based DevOps for Distributed Agile Projects (20)

Mais de Tom Stiehm

Mais de Tom Stiehm (7)

Último

Último (20)

Implementing Cloud-based DevOps for Distributed Agile Projects

Notas do Editor