Strategies for efficient delivery with APIs, containers, Microservices and DevOps

© OPITZ CONSULTING 2017
 überraschend mehr Möglichkeiten!
with APIs, Containers, Microservices, DevOps
Sven Bernhardt, Danilo Schmiedel
Strategies for efficient Delivery

Strategies for Efficient Delivery with APIs, Containers, Microservices,
DevOps
Seite 2
OPITZ CONSULTING - A success story since 1990
 Our Mission: Help organizations to leverage the possibilities of
digitalization to be different, better and faster than their competitors
 Owner-Managed company with
 400+ consultants
 11 locations in Germany and Poland
Danilo Schmiedel

 Managing Consultant
 Lead of Competence Center Cloud
About us
Sven Bernhardt
 Solution Architect
 Technical Lead of API Management

DevOps
Seite 3
Scenario #3: Innovation

DevOps
Seite 4
https://www.youtube.com/watch?v=98BIu9dpwHU

DevOps
Seite 5
https://www.youtube.com/watch?v=OKJK3_XIGD4

DevOps
Seite 6
Lots of buzzwords, concepts and techniques, but how to
find a beneficial mixture for Next-gen app development?
API Management
Microservices
Containers
Docker
DevOps
Continuous Integration
Continuous Delivery
Cloud
SOA
Integration

DevOps
Seite 7
Quelle: http://www.businessinsider.de/uber-self-driving-car-accident-arizona-police-report-2017

DevOps
Seite 8
https://www.youtube.com/watch?v=_GhODn4FRoE

DevOps
Often encountered in today’s IT system landscapes
Seite 9
Lack of innovation Missing knowledge
Lack of
maintainability
Decreasing data
quality
Decreasing benefit
Increasing costs
Lack of integration

DevOps
Seite 10
New ways on how to develop applications are needed to
manage agility (Bi-modal IT)
Standardization
Differentiation
InnovationNew ideas
Better ideas
Typical ideas
Customer-specific solutions
Standard Software solutions
Systems of Innovation
Systems of Differentiation
Systems of Record
Based on Pace Layered Application Strategy, Gartner 2012

DevOps
How to get there?
Seite 11

How to make it wrong?
DevOps
Risk 1 The initiative / program is a collection of individual IT projects
Risk 2 Requirements are just IT-driven
Risk 3 Unconditional belief in the platform vendors
Risk 4 Faith in error-free, unchangeable planning and roadmap
Risk 5 Lack of coordination between Business and IT
Risk 6 Start without clear goals and benefits
Risk 7 Underestimating efforts for changing legacy applications
Risk 8 Missing change management
Risk 9 Lack of coordination with other IT-related initiatives
Risk 10 Insufficient perception of complexity
Seite 12
Erhältlich als eBook auf heise.de

DevOps
Seite 13
Define the goals

DevOps
Seite 15
Download:
http://tinyurl.com/ydfdyqq9

DevOps
Solution architecture for the use case based on OMESA
reference architecture
Open Modern Enterprise Software Architecture(OMESA) | https://omesa.io
Credits to Luis Weir, Capgemini
Seite 16
User Experience
Service Implementation
Persistence
Web Mobile Device
Single Purpose API
Multi-Purpose API
Monitoring
BusinessAnalytics
Security
Management
Monolithic
System
RegistryEvent StoreShared Storage
Non-shared
Storage
Semi-decoupled Fully-decoupled
Seite 16

DevOps
Seite 17
OMESA reference architecture
Open Modern Enterprise Software Architecture(OMESA) | https://omesa.io
Credits to Luis Weir, Capgemini

DevOps
Seite 18
Main Objectives of OMESA
 All in all, OMESA has 4 main objectives:
1. To deliver a modern and enterprise-wide software reference
architecture suitable to combine ”existing" with the "new"
2. Provide guiding principles and definition of terms to ensure the
architecture can be interpreted and applied
3. Deliver a vendor agnostic capability model that can add tangible
business value to organizations
4. Bring back architectural best practices (based on real live
experiences) into modern solutions that are suitable for
organizations of any size and industry

DevOps
Seite 19
OPITZ CONSULTING - A success story since 1990
 Mission: Help organizations leverage the possibilities of digitalization to be
different, better and faster than their competitors
 Owner-Managed company with
 400+ consultants at 11 locations in DE and PL
 Revenue 2016: 47 Mill. €
Danilo Schmiedel

 Managing Consultant
 Lead for Competence Center Cloud
About us
Sven Bernhardt
 Solution Architect
 Technical Lead for API Management

DevOps
Seite 20
„We have a monolithic backend application. We would like
to slice the application into small functional building
blocks. Our challenge is to find the right size of these
building blocks according to our business requirements. “
Energy (E-Mobility) / Product Owner

DevOps
Seite 21
One approach to find the right service design
Domain Decomposition
 Derive services and respective data objects from your business processes,
which are here expressed in a standard notation like BPMN
Production
Logistics
Selling
Billing

DevOps
Seite 22
But: The Domain Decomposition approach is not trivial
 Very formal approach
 Knowledge with respect to the modelling notation (e.g. BPMN) is needed
and everyone needs to understand the model
 Might be time-consuming
 Disagreements regarding the business process flow
 Discussions about the modelling style (Is it correct in the sense of the spec?)
 Danger to model all process variants and edge cases (Lost in details)
 Need to know business domain and processes
 Risk to loose workshop participants, who might have important information

DevOps
Seite 23
Event storming as a more agile and lightweight approach
for identifying services and domains
 Event storming was invented by Alberto Brandolini (2013)
 Ingredients:
 Unlimited modelling space
 Sticky Notes
 Markers
 People from different organizational areas and levels (6-8 people)
 Facilitator
 Key terms:
 Event
 Command and External system
 Aggregate
 Bounded Context

DevOps
Seite 24Source: https://www.slideshare.net/ziobrando/model-storming, Slide 60

DevOps
Seite 25
Event Storming is a good approach for breaking up
complex business domains to manageable services
 Informal and easy approach, because there are no formal rules like standard
notations
 The right people are talking about their business domain, so it is ensured
that all questions can be answered
 Since it is not strictly formalized and everyone is invited to participate, the
approach is fun
 But, attention
 Good facilitation skills are needed and
 Workshop participants have to get involved

DevOps
Seite 26
„We have a historically evolved system. Today it is
hard for us to extend the system with new apps,
chatbots and location-based services because of
missing APIs.“
Professional Services / Head of Business Development

DevOps
Seite 27
Current situation: Monolithic custom-implemented ERP
application prevents innovation
 Complex system without
public APIs
 Controls whole business use
cases
 Difficult to maintain und
extend
 Fragile solution (each change
can lead to inconsistency)
 Needs to stay robust and
free from defects
Oracle Forms Client
Oracle ADF Application

(fuly-decoupled)
APIs
DevOps
Seite 28
Implementation platform overview – The big picture
Validation
Authentication
Throttling
Routing
{json}
{json}
{json}
Filtering
https://guidelines.axonivy.com/projects/guides/wiki/
Continuous_integration_delivery
Persistence
DevOps
Developer
CS
Container
CS
API
PlatformCS

(fuly-decoupled)
APIs
DevOps
Seite 29
Modernization based on
Oracle Cloud Services
Service
Implementation
(semi-decoupled)Validation
Authentication
Throttling
Routing
Transform
Orchestrate
{json}
{json}
{json}
Filtering
https://guidelines.axonivy.com/projects/guides/wiki/
Continuous_integration_delivery
{json}
Connect
API
PlatformCS
Container
CS
Integration
CS
Java CS
SOA CS
Developer
CS

DevOps
Seite 30
„We are in the process of establishing a centralized communication platform.
It is based on microservices but our development performance is not as
good as we expected. The available infrastructure does not scale. The
Developers are not very much motivated because of very slow feedback
cycles.“
Retailer / Head of IT Governance

DevOps
Seite 31
Agile software delivery is hard without a DevOps approach
 Fixed set of technologies (e.g. not Java,
Node.js and .Net), which might block
developers to use the most appropriate
technologies
 No DevOps approach because Software
delivery is the responsibility of another
team in a different organizational unit;
discussions with them are hard
 A consistent DevOps approach is needed
to be able to establish new services
efficiently within a short time-to-market https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Devops.svg/2000px-
Devops.svg.png

DevOps
Seite 32
It’s not a only technical thing; being adaptable and agile
concerns the whole organization
 Changeability is an essential prerequisite for becoming more agile and to
promote innovation
 Moving forward is basic for prospective success
 New collaboration approaches are needed to improve time-to-market
”It is not the strongest of the species that
survives, nor the most intelligent that survives. It
is the one that is most adaptable to change.”
(Charles Darwin)

DevOps
Seite 33
Continuous Delivery and Deployment for complex
Microservice architectures
Wercker
 Create custom CI/CD pipelines
 Chain & trigger pipelines to create complex workflows
 Speed up tests by running them in parallel
Source: http://www.wercker.com/platform

DevOps
Seite 34
„We are an enterprise company. Software
development is usually done by following
a waterfall approach. Our development
cycles are too long due to organizational
barriers and rules. On the other hand we
have to come up with new ideas and
innovations to improve our daily work.“
Manufacturer / CIO
Source: http://blog.procademysoftware.com/agile-
project-management/
Source: http://www.commonplaces.com/blog/agile-vs-
waterfall-how-to-approach-your-web-development-project/

DevOps
Seite 35
Be brave and promote innovation!
 Initiate digital innovation labs for trying new
ideas and technologies and leverage from PoCs,
Pilots, MVPs
 Involve those who are affected at an early stage
and ask for "advice"
 Earlier and quicker feedback on feasibility and
acceptance
 Change the attitude: “From suit to hoodie
wearer“
 Change the mentality: “Be ready to fail, adjust
and try again.”
PoC
Pilot
MVP

DevOps
Seite 36
Get support from Outside
Innovation Lab as a Service (ILaaS)
 Guru Co-working space
 From office space, support from experts,
coffee and water => all inclusive for a
monthly fee
 Example use cases:
 Supporting and optimizing existing processes with
Mobile apps
 Hololens for supporting the production process
 GPS tracking use cases
Source: http://blog.procademysoftware.com/agile-
project-management/
Source: http://www.commonplaces.com/blog/agile-vs-waterfall-how-to-
approach-your-web-development-project/

DevOps
Seite 37
ILaaS Approach
 Choose manageable use case
 Fixed iteration length (approximately 4 weeks)
 Development ends with a Minimal Viable Product (MVP)
 Define basic solution architecture
 Choose implementation platform & approach
 Staff team
 Technicians (Implementors / Architects)
 Business stakeholders
 Implement MVP
 Review
Re-/Define
use case
Define
solution
architecture
Choose
platform
Staff team
Implement
MVP
Review
Feedback
Feedback
FeedbackFeedback
Feedback
Withdraw
Solution not
applicable?

© OPITZ CONSULTING 2017 Modernize Your IT Landscape with API-Driven Architectures Seite 38
API Management is the key to ensure agility
Phase 1 Phase 2
✓ Finalized definition of the single-purpose APIs on day two in a
collaborative way with Apiary
✓ Independent development of Mobile app, Mobile Backend, Backend
Service and API
✓ Problem: Connectivity to the backend system, because Firewall
changes took too long (4 weeks project duration, connectivity was
available in week 3)
✓ Development team was not blocked because implementation of the
mobile app was done against the Mock Server functionality in Apiary

DevOps
Seite 39
It‘s all about change!

Plan you next steps
DevOps
Microservices
DevOps0%
DevOps
100%
DevOps
0%
Microservices
100%
Microservices
Backend for Frontend (BfF)0%
BfF Usage
100%
BfF Usage
Decoupling Backends
from Frontends
Use of
Microservice architecture
Establish a
DevOps approach
API-Management0%
API-Mgmt.
100%
API-Mgmt.
Use of
API Management
Application platform0%
Platform
100%
Platform
Implement an
application platform
Seite 40

DevOps
Seite 41
Summary
 Understand the business goals and design properly (e.g. Event Storming)
 API Management is the key to ensure agility
 Ability to change, which means the way
 how architectures and applications are designed and implemented
 collaboration between different stakeholders happens
 how processes and procedures are used
 Attitude: “From suit to hoodie wearer”
 Mentality: “Be ready to fail, adjust and try again”
 Microservices and DevOps belong together and both are not just tools

 überraschend mehr Möglichkeiten!
@OC_WIRE OPITZCONSULTING opitzconsultingWWW.OPITZ-CONSULTING.COM
Seite 43
In case of any questions, please contact
us!
Danilo Schmiedel
Managing Consultant Solutions | Oracle ACE Director
OPITZ CONSULTING Deutschland GmbH
Tempelhofer Weg 64, 12347 Berlin, Germany
Phone: +49 173 7279001
Mail: danilo.schmiedel@opitz-consulting.com
@dschmied
http://inside-bpm-and-soa.blogspot.com
Sven Bernhardt
Solution Architect | Oracle ACE
OPITZ CONSULTING Deutschland GmbH
Kirchstrasse 6, 51647 Gummersbach, Germany
Phone: +49 172 2193529
Mail: sven.bernhardt@opitz-consulting.com
@sbernhardt
https://svenbernhardt.wordpress.com
DevOps

Strategies for efficient delivery with APIs, containers, Microservices and DevOps

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Strategies for efficient delivery with APIs, containers, Microservices and DevOps

Ähnlich wie Strategies for efficient delivery with APIs, containers, Microservices and DevOps (20)

Mehr von Sven Bernhardt

Mehr von Sven Bernhardt (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Strategies for efficient delivery with APIs, containers, Microservices and DevOps