Once-stable industries are rapidly being disrupted as companies move toward digitalization by embracing software at their core. Deploying cloud-native application architectures is at the center of how these businesses are fueling their disruptive character.

1. MICROSERVICES
EVOLVING YOUR ARCHITECTURE TO
HECTOR TAPIA
DIRECTOR OF PRESALES
WEST & SOUTH REGION

2. SOFTWARE AS A COMPETITIVE ADVANTAGE
Lots of people talk about these companies and use them as examples of how innovation
disrupts the marketplace
What does these innovative companies have in common?
• Speed of innovation
• Always-available services
• Web Scale
• Device-centric user experiences
• Recover from failures quickly
CLOUD-NATIVE APPLICATION ARCHITECTURES
ARE KEY TO ENABLE THE BUSINESS MODEL
THAT ALLOWED THESE COMPANIES TO OBTAIN
THEIR DISRUPTIVE CHARACTER.

3. WHY CLOUD-NATIVE APPLICATION ARCHITECTURES?
Speed Safety Scale

4. CLOUD-NATIVE APPLICATIONS ARE ARCHITECTED DIFFERENTLY
Two common examples of Cloud-Native Applications are:
TWELVE-FACTOR APPLICATIONS & MICROSERVICES
• Every integration point will eventually fail one time or another
• Be prepared to handle all kinds of failures
• All functionality is published and consumed via Web Services
• Designed for Scale Out
• Break down the task, process requests asynchronously
• Use messaging to decouple functionality
• Eventual consistency model
• Build stateless services that can be scaled out and load balancedStateless Model
Asynchronous Processing
Horizontal Scalability
Handling Failures
Services
Two common examples of Cloud-Native Applications are:
Twelve-factor Applications & Microservices

5. 5
Microservices
Is a way of designing software
applications as suites of
independently deployable
services
Wall-E Copyright Disney/Pixar

6. WHY DO WE NEED MICROSERVICES?
Service Oriented Architecture
Software architecture design pattern
based on distinct pieces of software
providing application functionality as
services to other applications

7. Even services can be designed monolithic and we can still call them Service
Oriented
• Slow development
• Irrelevant works
• Big fat services
• Endless restarts
• Reusability issues
• Missing refactoring

8. MICROSERVICES VS. SOA
“Microservices is a specific flavor of SOA. Due to unique features, it deserves a name.”
Martin Fowler
“If every service has to be updated at the same time, it’s not loosely coupled”
Adrian Cockcroft
“Focus on building services that make development and deployment easier, not just tiny
services”
Chris Richardson

9. MUST BUILD SOFTWARE FOR INNOVATION AND DIFFERENTIATION
75% By 2020, 75% of Application Purchases
supporting digital business will be
“Build”, not “Buy”.
Forecast Analysis: Enterprise Application Software,
Worldwide, 2Q15 Update

10. NOT EVERYBODY IS READY, NOT EVERYTHING IS CLOUD-NATIVE
CLOUD-NATIVE ORIGINATED IN CUSTOMER FACING TECH COMPANIES
Traditional Enterprises
• Spend 2-4% of revenue on R&D
• Employ “normal” people
• Enterprise-scale
• Thousands of apps
• Technology seen as an
investment
Customer-Facing
Technology companies
• Spend 20%+ of revenue on
R&D
• Employ highly paid developers
• Internet-scale
• Technology is their business

11. HOW TO EVOLVE YOUR
APPLICATIONS TO
MICROSERVICES

12. • Minimize service dependencies
• Evolution mechanism in service contracts
• Split features around business capabilities
• Keep logic not on layers, on everywhere

13. TRADITIONAL WEB APPLICATION ARCHITECTURE
Customer Profile
Service
Catalog Service
Order Service
Payment Service
User Interface
J2EE Application Server
DB
MVC
Load
Balancer
WAR

14. Load
Balancer
HTTP/S &
TCP Router
PERFORM A FUNCTIONAL DECOMPOSITION OF THE APPLICATION
Customer Profile
Service
Catalog Service
Order Service
Payment Service
User Interface
MVC
DB
WAR
WAR
WAR
WAR
WAR
Cloud Platform
(AWS, CloudFoundry, etc.)

15. TWO LEVELS OF ARCHITECTURE
System-level
Services
Inter-service glue: interfaces and communication mechanisms
Slow changing
Service-level
Internal architecture of each service
Each service could use a different technology stack (polyglot)
Pick the best tool for the job
Rapidly evolving
Chris Richardson

16. PARTITIONING STRATEGIES
• Partition by Noun
• e.g. Product, Info, Service
• Partition by Verb
• e.g. Checkout, Order
• Single Responsibility Principle
• Inverse Conway’s Law – teams own service groups
• Unix style: Do one focussed thing well
• Size doesn’t matter

17. Load
Balancer
HTTP/S &
TCP Router
PICK THE BEST TECHNOLOGY FOR EACH SERVICE
Order
Management UI
Browse Products
UI
Account
Management UI
Checkout UI
Customer Profile
Service
Catalog Service
Order Service
Payment Service
DB
DB
ESB / ETL
Cloud Platform
(AWS, CloudFoundry, etc.)

18. Infrastructure
Host Operating System
Hypervisor
Bin & Libs
Guest OS
Application
Bin & Libs
Guest OS
Application
Bin & Libs
Guest OS
Application
Virtualization: Includes
the application, the
necessary binaries and
libraries and the entire
guest operating system
- All of it can be tens of
GB’s in size
Infrastructure
Hypervisor
Containers: Include the
application and all of its
dependencies, but share
the kernel with other
containers, running as an
isolated process in the user
space on the host OS with
Built-In Policy.
Linux Kernel
InstanceManager
Application
Application
Application
Application
Application
A MICROSERVICES ARCHITECTURE DOESN’T DICTATE THE USE OF CONTAINERS
BUT MOST ORGANIZATIONS THAT MOVE TO MICROSERVICES ARCHITECTURES WILL FIND CONTAINERS TO BE A PERFECT MATCH
• Runtime options and portability
• Finer-grained execution environments
• Better isolation allows for component cohabitation
• Faster initialization and execution

19. APPLICATION DEVELOPMENT LIFECYCLE
PAST AND PRESENT
Methodology
Process
Patterns
Platform
Waterfall
Gated
Monolithic
Windows
Agile
Scrum
N-Tier Layered
Windows/Linux
Lean Engineering
CI / CD
Microservices
Cloud

20. NEW REQUIREMENTS FOR DEVELOPERS AND OPERATIONS
Development:
Microservices
Packaging:
Containers
Deployment:
Cloud Infrastructure
• Fast, tested, fail safe, small changes continuously deployed to production
• Measure, share visibility and provide feedback of users to business,
continuously
• Small experiments, test assumptions, fail fast and learn!

21. SOFTWARE AG TECHNOLOGY
FOR MICROSERVICES

22. UNIVERSAL MESSAGING
MICROSERVICES ARCHITECTURES RELY ON MESSAGING FOR INTER-SERVICE COMMUNICATION
Universal Messaging has key characteristics that
add value in a Microservices architecture
• Multiple wire protocols including JMS, MQTT
and Web Sockets
• Multiple transport protocols
• Unicast, Multicast,IPS
• Runs on Docker Containers
• Supported as a Service in Pivotal Cloud-
Foundry
• Messaging APIs

23. TERRACOTA BIGMEMORY GO
MICROSERVICES IN-MEMORY DATA MANAGEMENT
Microservices architectures promote one single
database per service
• BigMemory Go being open-source is
perfect self-service provisioning among the
developer community
• Runs on Docker Containers
• Will run on Pivotal Cloud-Foundry
• When going into production, CIOs will want
“Enterprise Capabilities”, turn to
BigMemory Max
• In-Memory databases are perfect for the
kind of applications targeted with
Microservices which are “Customer Facing”

24. API GATEWAY
INTEGRATE, SECURE AND MONETIZE MICROSERVICES
• Assure continuous
integration and testing
in DevOps
• Speed up the
development cycle
• Deliver higher-quality
software faster to meet
customer satisfaction
goals
• Secure external access
to backend services

25. APAMA
STREAMING ANALYTICS
For most applications, the way to make Microservices work and to manage distributed data successfully is
to adopt an event-driven architecture
In an event-driven architecture, a service publishes events when something notable happens, such as
when it updates a business object. Other services subscribe to those events. In response to an event a
service typically updates its own state. It might also publish more events, which then get consumed by
other services.
• Apama not only provides
the Event-Source needed
but full capabilities to
develop Event-Driven
Streaming Analytics
Microservices
• Runs on Docker, on IoT
devices, everywhere!

26. WEBMETHODS DEVOPS EDITION
CONTINUOUS DELIVERY OF MICROSERVICES CHOREOGRAPHY AND WEB SERVICES ORCHESTRATION

27. Software AG webMethods
Unified Service Delivery Platform that allows you to:
Connect your existing systems using Event Enabled integration
Build new Event applications using reusable services
Automate processes
Govern your services during design-time and run-time
it provides way more functionality than an ESB

28. INTEGRATION
DATA
(EVENTS)
ESB
IF IF
BUSINESS
LOGIC
TASKS
(PROCESSES)
DECISIONS
(RULES)
DIGITAL BUSINESS PLATFORM DESIGNED FOR MICROSERVICES
Release
Plan
Release
Plan
Release
Plan
Release
Plan
Release
Plan
Release
Plan
Developer
Deploy Feature to
Production
Deploy
Standardized
Services
Developer
Developer
Developer
Developer
Developer
Deploy Feature to
Production
Deploy Feature to
Production
Deploy Feature to
Production

29. DEMONSTRATION
CLOUD-NATIVE APPLICATION BASED ON SOFTWARE AG DIGITAL BUSINESS PLATFORM