Schuberg Philis

Devops and Cloudstack at Schuberg Philis – Why?

Schuberg Philis is an independent company

» Schuberg Philis is a privately owned company in which management and employees hold 100% of the shares

» No banks or other forms of external capital are involved, resulting in a debt-free, fully equity financed company

» Schuberg Philis currently has 130 million EUR contracted revenue

2004 2005 2006 2007 2008 2009 2010 2011 2012

40 50

65

85

101

118

149

170

190

2004 2005 2006 2007 2008 2009 2010 2011 2012

6.59.0

13.2

20.2

30.4

35.0 42.5

47.5

56.0

2004 – 2012 show significant growth with sustaining customer satisfaction

Customer Satisfaction (Scale 1-10)

FTE

Revenues (in € 1.000.000)

2004 2005 2006 2007 2008 2009 2010 2011 2012

7.27.7

8.78.2 8.1

8.5

8.9Chart Title

Axis Title

Axis Title

NDA Customer 1NDA Customer 2

We believe

can make the difference

Key values of Schuberg Philis

» Ownership» Commitment » Dedication » Embracing change » Responsibility vs Freedom» Result driven» People over process» Transparent» Exceed expectations

We are still debating shape and form, but we need to codify our values for sure

» Pride» Craftsmanship» Self conscious » Authentic » Convinced» Vulnerable» Determined» Innovative» Adaptability

» Open Minded» Not risk averse» Challenging» Competitive» Charm» Faith

Customer demand towards outsourcing services has changed . . .» As complexity increases integration of services becomes a challenge and

specialized services are required

» More focus on fulfillment of business needs: – The ever shorter Time-to-market– Flexibility & scalability of provided IT systems– Increased security & regulatory demands while– Keeping uptime at par

» Customers require partners to advise them on potential improvement areas within their own organizations

» Economic reality: more for less

The four cornerstones of Schuberg Philis

100%

Teams

Technology

Co-Creation

Focus

We focus on applications that

society and businesses

rely on

Mission critical applications have different characteristics

Generic» Standardisation / scale» Cost vs. user acceptance» Low integration with core business» Escalation based decision making » Low EBIT impact

Critical applications» Integration / specialists» Cost vs. business risk» High integration with core business» Business focus» High EBIT impact» Time 2 market

Generic

Critical applicationsCosts vs Risks

We build dedicated customer

teams

with full context and responsibility

SBP Team members cover all required areas of expertise

With model A, in case of vital applications, the law of diminishing returns applies.

Schuberg Philis operates according to model B

Model A Model B

Partner

Customer team

Partner

Customer team

Partner

Customer team

Partner

1st line

2nd line

3rd line

Quality Control / Self Assessment

Service / Project management

Monitoring / Event management

Datacenter / Network

Support Systems / Processes

Generic

Critical applicationsCosts vs Risks

What you see is what you get

Hand overPotential conflict

Hand overPotential conflict

Clear expectation management

Plan

Plan Build Run

RunBuild

We create settings of

co-creation

where we collaborate with our customers and partners

The CIO / CDO of enterprises adapted always

- From central administrative mainframe tasks to - Decentral rich LAN environments to- Centralized Web applications for all to- Distributed environments- Centralizing workforce- Outsource Office Automation- Outsource specific lots, etc..

The focus is always on - Time to Market- Uptime- Cost / Risk and- Security

In the traditional IT organization there is a wall of confusion

Business Operations

Schuberg Philis key deliverables (2003 - now)

Project Phase- TTM Transition project: Customers do not have to fear the cost of transition- Not in cost (fixed Price) and not in duration (we never missed a deadline)- Application Infrastructure Integration with full DR testing- Layer3 and Layer7 designs are key- All infrastructure behavior is monitored within SBP- DTAP model to ensure robustness

Run Phase- Guaranteed 100% uptime: We have fixed the application shortcomings with

Infrastructure- Infrastructure is dedicated and often has physical characteristics (planned

downtime is possible)- First part of Co-Creation on Release Management and Change Management

processes

A

Schuberg Philis key deliverables (2007 - now)

Project Phase- Infrastructure is highly virtual (<2013) or cloudified (>2012)- Monitoring Infrastructure and Applications shared with customers- Set up agile working methods, iterative designs

Run Phase- Change windows have less or no downtime due to virtualization- Application behavior / resilience is used in start / stop procedures- Co Creation extends to Functional Application Maintenance Departments

B

Schuberg Philis key deliverables (2011 – now)

Project Phase- Infrastructure is flexible and integrates with others by using SDN (Software

Defined Networking)- Everything that moves is measured, infrastructure and code- Developers and SBP Create joint continuous delivery platform

(git/github/jenkins/tfs)- Pipelining next to DTAP- Implement full scrum or kanban together with customers and development

parties

Run Phase- Co Creation: Developers can push (a lot off) changes to prod, Developers are

standby as well- Continuous delivery, Integration requires continuous Feedback loops - Behavioral / anomaly analyses with big data (rrd / graphite / hadoop /

opentsdb / tableau)

C

Co-creation: open source

Open or closed source. Functionality is key so:

For open source that means that we use open source products, - when we can afford it to contribute back- when we predict that the life cycle of the product is long enough- if the skills we gain benefit us (employee and company in the long run)- If we want to be member of the community

This means open source is not free, but it means a high level of control as well

Co-creation: Closed source

Closed source products are chosen if:

- They are best of breed (e.g. splunk, Nexenta)- They are open enough to interact with other tools (e.g. they have an API)- We can work directly with labs or dev departments on features and issues

No or limited co-creation if- We need quantitative support (e.g. Netapp, EMC, Xen, ESX)- If the product, tool, or infra component does not has a high change frequency

(e.g. Oracle, Cronacle)

We are passionate about

Technology

and design fit for purpose based on our customer’s business requirements

Technology

• Supporting customer requirements• Technology choice agnostic design (L3 and L7)• Automate everything• Innovate with sense• Best of breed (Open and closed source)• Direct interaction with customer by engineer• Enabler : stability, • Cocreation with Technology Vendors

Infrastructure management – IAAS on a scale

Dedicated Physical

Environments

Level of control

Public Clouds(Amazon,

Azure, etc.)

Private Mission

Critical Cloud

Shared Mission

Critical Cloud

Flexibility

Dedicated Virtualised

Environments

Infrastructure model depends on requirements:• Availability • Flexibility • Confidentiality• Integrity• Compliancy• Cost• Control (risk)

Infrastructure models managed by Schuberg Philis for customers

Possible to categorize workloads into two sets (slide from Shannon Williams TM )

Cloud Workloads

Traditional Workload

Reliable hardware, backup entire cloud, and restore for users when

failure happens

Distributed Workload

Tell users to expect failure. Users to build apps that can

withstand infrastructure failure

Both types of workloads must run reliably in the cloud

Service Integration over stacks

New issues at the horizon:- Where does my data live? Local Datacenter? Remote Datacenter? Cloud? - Where do my apps reside? Local Datacenter? Etc..- Who is making these judgments over IAAS layers?- Can I pay OPEX and not CAPEX? Pay per use?- How do I scale down (remember data and VM growth explosions)?

How to achieve true Integration?

Secu

rity S

erv

ices

Data

Pro

tectio

n S

erv

ices

Com

plia

ncy

and a

udita

bility

Service Integration

Inte

rfacin

g

Applica

tion M

anagem

en

t

Inte

rfacin

g

Applica

tion M

anagem

en

t

Applica

tion M

anagem

en

t

Applica

tion M

anagem

en

t

Applica

tion M

anagem

en

t

Applica

tion M

anagem

en

t

Applica

tion M

anagem

en

t

Infrastructure Management

Application Landscape Integration

Monitoring and Reporting

Application Management: Automate

Automate and report Application build

weeks

Level of

au

tom

ati

on

high

low

Application Management depends on requirements:• Application stack• Availability • Flexibility • Confidentiality• Compliancy• Cost

Maintain Infrastructure Configuration Repository

Implement and Maintain Joint Application Code Repository

<days

Automated Application Testing

Continuous Integration

(Automated) Applications Logistics (DTAP)

Automate Application Deployment

The Devops side of things

Culture is key!

Automate Infra, Application, Monitoring and Integration!

Measure anything that moves, alert on everything that matters

Share what you have got, its about the issues that have not been solved

Questions?

If you have questions later: - Mail: aeriks@schubergphilis.com- Twitter: DrozerT

Questions?

Twitter: DrozerT

CU Tomorrow @