Evolving your Architecture to MicroServices
6 likes302 views
The document discusses the transition to microservices and cloud-native application architectures as essential for modern businesses seeking innovation and competitive advantage. It highlights the differences between microservices and traditional service-oriented architectures, emphasizing the need for scalability, flexibility, and resilience in application development. Additionally, it addresses the importance of adopting event-driven architectures and utilizing tools like messaging and in-memory data management to enhance microservices functionality.
Evolving your Architecture to MicroServices
- 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