Recommended
More Related Content
What's hot
What's hot (13)
Similar to Microservices without PaaS is like Bavaria without Beer
Similar to Microservices without PaaS is like Bavaria without Beer (20)
Recently uploaded
Recently uploaded (20)
Microservices without PaaS is like Bavaria without Beer
- 1. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Microservices without PaaS is like Bavaria without Beer Johannes Engelke
- 2. © 2016 SAP SE or an SAP affiliate company. All rights reserved. What is the Value of Beer? Cleaner than Water Easier to store (last longer) More fun Lots of calories
- 3. © 2016 SAP SE or an SAP affiliate company. All rights reserved.Find the Video: https://speakerdeck.com/caseywest/said-no-ceo-ever-things-that-dont-matter-in-the-cloud Said no CEO ever (by @caseywest) ”Good job picking a linux distro.“ — No CEO Ever ”Nice work deploying software.“ — No CEO Ever ”Nicely done logging infrastructure.“ — No CEO Ever ”✋😎 Thanks for using containers!“ — No CEO Ever ”I’m glad you built a monitoring system.“ — No CEO Ever
- 4. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Let’s put it into a Diagram OS Container Programming Language Your Functional Solution
- 5. © 2016 SAP SE or an SAP affiliate company. All rights reserved. From Monolith to Microservice UI specialists middleware specialists DBAs Siloed functional teams … … lead to siloed application architectures. Because Conway’s Law Cross-functional teams … … organised around capabilities. Because Conway’s Law http://www.martinfowler.com/articles/microservices.html
- 6. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Microservice from Ops perspective Loadbalancer Database OS Runtime Loadbalancer Database Runtime OS Loadbalancer OS Runtime Database AUTO- MATE EVERY- THING!
- 7. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Well… Update ScalingInstallation Security MonitoringCost Backup
- 8. © 2016 SAP SE or an SAP affiliate company. All rights reserved. You build it you run it MongoDB Golang etcd NodeJS RedHat F5 HAProxy Ubuntu AWS ELB Gentoo Java Postgre Loadbalancer Database OS Runtime Loadbalancer Database Runtime OS Loadbalancer OS Runtime Database
- 9. © 2016 SAP SE or an SAP affiliate company. All rights reserved. From Monolith to Microservice … lead to silod application architectures. Because Conway’s Law MongoDB Golang etcd NodeJS RedHat F5 HAProxy Ubuntu AWS ELB Gentoo Java Postgre Loadbalancer Database OS Runtime Loadbalancer Database Runtime OS Loadbalancer OS Runtime Database
- 10. © 2016 SAP SE or an SAP affiliate company. All rights reserved.
- 11. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Let’s put it into a Diagram OS Container Programming Language Your Functional Solution
- 12. © 2016 SAP SE or an SAP affiliate company. All rights reserved. PaaS: Technical PaaS Your Functional Solution
- 13. © 2016 SAP SE or an SAP affiliate company. All rights reserved. PaaS: Organizational
- 14. © 2016 SAP SE or an SAP affiliate company. All rights reserved. PaaS: Commercial
- 15. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Opinionated PaaS Opinionated Beer Unopinionated Beer
- 16. $ cf create-service db-service silver mydb -c '{"ram_gb":4}’ $ cf push myapp $ cf bind-service myapp mydb -c '{"permissions":"read-only"} $ cf restart $ cf scale myapp –i 5
- 17. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Unopinionated PaaS Guidance Support and Consultancy Central Services Templates / Shared Ops Code
- 18. © 2016 SAP SE or an SAP affiliate company. All rights reserved. Summary PaaS Developer ManagementService Developer
- 19. © 2016 SAP SE or an SAP affiliate company. All rights reserved.
- 20. © 2016 SAP SE or an SAP affiliate company. All rights reserved. THANK YOU
- 21. © 2016 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. See http://global.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices. © 2016 SAP SE or an SAP affiliate company. All rights reserved.
Editor's Notes
- Introduction: Johannes Engelke Working for about 7 Years in system automation / PaaS, how ever you call it (running things) 3 of them in SAP Hybris yaas.io project Love Beer
- German purity law 1516 Beer has some more serious values: It was more healthy and noneperishable then water Lots of Calories Clean At least it should be Due to lack of knowledge they added Strange ingredients They used Cerials which where better used in backeries To save money they added not enough of the ingredients or added water after brewing Not like Today The basics where known: Take a bit of Wheat or barley Add Water and hops Cook it Wait (fingers crossed, it will work or not…) Done Add some magic ingredients e.g. Eber Geifer (boar spittle), some (probably unhealthy) herbs, put a rope of a hangman below the barel etc. They did even more strange things to get the Beer thing going Beside this: Wheat and Rey was used for Bread too The brewing was forbidden for some time, if there was less food available As Beer was staple food, it was quiet important to have enough in good quality for a reasonable price Barley was not used for backing bread 23. April 1516 durch die bayerischen Dukes Wilhelm IV. und Ludwig X. in Ingolstadt erlassen. Water Barley Hops We will come to it later
- https://speakerdeck.com/caseywest/said-no-ceo-ever-things-that-dont-matter-in-the-cloud Casey West did a great talk at the London Platform User Group about what really matters in the cloud. We are doing a lot of things during the day, nobody cares about. Even today, we are talking about Microservices. Actually who cares? Our customers? Our Investors? Our CEO?
- Reduce cost of not value generating things Concentrate on your business
- Just to bring us on the same page, a short look at the differences between microservices and monlith applications. I guess you all know this pictures. I stole it from martin fowler. In a monolithic wold teams are organized around technical responibilities. There are the UI, the App and DBA guys. Most likely the middleware spacialists don’t understand the business of the UI and DBA’s The DBA’s don’t understand the App and the UI teams Same for the UI team And porbably all of them do not understand the business at all On the other hand the “Happy” Microservice world. (don’t get me wrong, I like the concept and it makes absolute sense to work in this way) Teams are organized around business capabilities UI, DBA’s and App people are sitting in the same team and shipping services including persistence, UI and application logic. Let’s focus a bit more what a microservice is As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions. -> http://www.martinfowler.com/articles/microservices.html
- Installation: Easy thing apt-get install, done Cluster Setup? Hardening? Tuning? Updates: Testing Downtimless / Rolling Scaling: No Downtime Most of the time tricky for backingservices Backup: Easy, just doit Desaster Recovery Tests? Chaos Monkey? Cost: Calculate and predict the cost per call / user in advance The price per call / user has to cover the cost No Investment Every cent less on this side will be revenue or can be spend in further development Security: Network layer security OS Layer Security Service Layer security Company requirements Concepts (e.g. Dataprivacy concept etc.) Monitoring: Setup propper monitoring rules React on incidents More components more trouble Know How to troubleshoot
- As you can see the approach overloads any kind of Ops Organization. They will not be able to run all this different services. At least if Devs are picking every day a new technology they like to use. So what about you build it you run it? It will work Every team will pick, what they like All of them will reinvent the wheel (to a certain degree) Reduce Team velocity Probably reduce quality, because Focus is still on Features Much duplication Hell on earth for overarching roles e.g. Security
- Let’s compare it with our good old monolith… Which one is cheaper? Which one is faster to install? Which one is (in ops) easier to maintain? Just to keep in mind: Many monolith deployments are not automated at all (and they still make money) So there is a lot of potential of just automating a monolith insted of going into direction of microservices To make it short: If we like to work in a microservices world we have to reduce operations costs really hard. Just if you question, why should you care about? – Currently we are working in a world, where smb. Will pay you 4.5 EUR a Month for a simple todo list app. But this will change really quickly! More competitors are comming up Besides Features cost will influence the decision With high Ops cost not money for new compeeing features
- 23rd April 1516 the bavarian Dukes Wilhelm IV and Ludwig X signed in Ingolstadt the German Purity Law Technical (ingredients) Organisational (When to brew) Comercial Regulations (Beer price, Units) Common Quality standard Reduced problems with ingredients Organized that it is available for everybody for a reasonable price Water Barley Hops
- With this in mind back to our picture form the beginning. - How can we reduce the “useless” work?
- PaaS (Platform as a Service) Management of VM’s Runtime Maybe container (if based on) Backingservices e.g. Databases Routing Monitoring Scaling Etc.
- Organizational topic: Everything is self service Deploy your app within minutes Request resources (databases etc.) minutes Scale within seconds Direct access to monitoring and metrics data Defined interfaces between PaaS and your app (no ticket ping pong till all information is in place)
- Commercial: Be transparent about cost Provide visibility about current consumption
- Everything is good now? Kind of, but there are different PaaS Solutions out there and probably everybody likes to call his solution paas Containers? Will it be a PaaS if it is Language aware? Probably yes, but there are different quality levels We talked about PaaS as a solution for our Problems. With most of the things, you could do it depends Only a opinionated paas will solve our problems A unopinionated PaaS (e.g. Kubernetes, docker etc.) might solve some issues Same problems How to updated How to configure Etc. Just IaaS on a different level Opinionated PaaS will define how to build you software but will take care of all the other things you need 12 Factor App How to deploy (cf push, buildpacks) Set of basic services (e.g. mongodb, postgre etc.) is available Can be consumed about a std. API contract (service brokers) Scaling Rolling updates Etc. Still gives you the freedom of choice (use different Programming languages, add parts by leveraging the IaaS level, multiple points to configure)
- There are ready made solutions e.g. Cloudfoundry, deis, flynn At least Cloud Foundry can be bought with already integrated backingservices You can install them onPrem (Pivotal CF, deis, flynn) Use exsisting offerings like bluemix, heroku etc. All of them are supporting buildpacks, which allows to deploy many different programming languages. All of them are using containers under the hood. Just a few simple commands brings your app into production
- If you like to opt for an unopinionated PaaS, go for it, but you have to keep some things in mind: Provide Cetral Backingservices (to reduce Ops overhead) Provide Guidance (to have similar solutions for different teams) Have Architects / Devops Teams who could offer support and consultancy Share everything (make sure teams are not implementing things twice and share experiences)
- As a Infrastructure / PaaS Developer Automate everything Everything should be selfservice Small and scalable vs. big and enterprisy Be fast Care about the developers As a Service Developer Focus on features Leverage the Plattform as much as possible Adjust vs. Create A Workaround might be a better solution then running the perfect fit by your own As a Development Manager Invest into the plattform Invest in things many team could use Force teams to make use out of it Be open to new technologies
- Finally about our beer: At some point the law was extended to brew beer out of wheat too Was a big success Lot of Tax