Using containers to build a microservices architecture
âąAls PPTX, PDF herunterladenâą
1 gefĂ€llt mirâą1,832 views
Microservices are more than just building software. There are questions around architecture, your organization, processes and your way of thinking. Innovation does not come naturally to everyone, so let's explore the journey you need to take as you leverage your current architecture and learn how the foundational building blocks to microservices are containers. Event site: https://www.redhat.com/en/about/events/containers-enterprise-red-hat-virtual-event
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ăhnlich wie Using containers to build a microservices architecture
Ăhnlich wie Using containers to build a microservices architecture (20)
Mehr von Eric D. Schabell
Mehr von Eric D. Schabell (20)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
Using containers to build a microservices architecture
- 1. Using Containers to Build a Microservices Architecture Eric D. Schabell
- 2. THE JOURNEY Are you doing microservices today? Architecting the future Containers as the foundation 2
- 3. We need to innovate, not just keep up⊠(Red Queenâs Race) 3
- 4. Not innovative... targeting efficiency 4Source: Dave Gray, The Connected Company
- 5. Value delivered through services, not just mass production of product. 5
- 6. 6 To deliver services which provide value, we need to listen and react. We need to deal with variety.
- 7. Driving innovation through IT 7 Decentralized decision making Purpose driven Innovation: admit you donât have all the answers figure out how to ask the right questions
- 8. 8 âPeople try to copy Netflix, but they can only copy what they see. They copy the results, not the process.â -- Adrian Cockcroft, former Chief Cloud Architect, Netflix You donât need to worry about Netflix, you need to be afraid of the barbershopâŠ.
- 9. So⊠are you doing microservices today? 9 Maybe it doesnât matter so much⊠What we really care about is speed, reduced time to value, and business outcomes.
- 11. âOrganizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.â -- Melvin Conway 11
- 12. As defined by Red Hat âMicroservices is an architectural approach, that emphasizes the decomposition of applications into single-purpose, loosely coupled services managed by cross-functional teams, for delivering and maintaining complex software systems with the velocity and quality required by todayâs digital businessâ 12
- 13. Break things down (organizations, teams, IT systems, etc) down into smaller pieces for greater parallelization and focus on reducing time to value. 13
- 14. Why break things down? Single, self-contained, autonomous, isolated and Resilient to faults Faster software delivery and own their own data Easier to understand individually Scalability Right technology for the problem Test individual services Individual deployments 14
- 15. Are you doing microservices today? Using self-service infrastructure and application automation... Have working CI/CD... Have health checking, monitoring, instrumentation... Have logging, distributed tracing... Able to release services independently... Honoring backward and forward compatibility... So⊠15
- 16. CONTAINERS AS THE FOUNDATION 16
- 17. 17 Remember, microservices is about optimizing⊠...for speed
- 18. Are you doing microservices today? Using cloud enabled self-service infra.. Using cloud enabled self-service application automation... Have working CI/CD to your private cloud... Have health checking, monitoring, instrumentation in your cloud... Able to release services independently... Honoring backward and forward compatibility... So⊠18
- 19. The answer should start with... OpenShift Container Platform Team self service application deployment, CLI/IDE/Web based tooling Developer workflow, build/deployment triggers, Jenkins Pipeline out of the box Enterprise focused (LDAP, RBAC, Oauth, Kubernetes,etc) Integrated container registry Software Defined Networking (SDN) Container native format/packaging 19
- 20. 20 OPEN INNOVATION LABS COLLABORATION Space to work, innovate, and discuss RESIDENCY An eight-week accelerated teaming engagement COMMUNITY INCUBATION Communities supporting innovation
- 21. FUTURE OPPORTUNITIES 21 Install OpenShift Container Platform in minutes https://github.com/redhatdemocentral/ocp-install-demo Red Hat Demo Central - App Dev in the Cloud examples https://github.com/redhatdemocentral Book: Microservice for Java Developers https://developers.redhat.com/promotions/microservices-for-java-developers Learn more about Red Hat Summit at redhat.com/summit
- 22. THANK YOU 22
Hinweis der Redaktion
- For Container Virtual Event, Jan 2017, presented by Eric D. Schabell, Global Technology Evangelist, Red Hat. Reachable at @ericschabell and erics@redhat.com.
- Letâs start this journey with a question, âAre you doing microservices today?â This might be yes, maybe or not sure, but letâs examine the story of microservices, what an architecture needs to look like and why containers are the foundation to make your microservices journey easier.
- The red queen race! Keeping up with competitors, keeping up with consumers, markets etc. Lewis Carrollâs âAlice in Wonderlandâ âin our country â said Alice, still panting a little âyou'd generally get to somewhere else â if you run very fast for a long time!â âA sort of slow countryâ said the queen... âNow, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!â https://en.wikipedia.org/wiki/Red_Queen_hypothesis An evolutionary hypothesis which proposes that organisms must constantly adapt, evolve, and proliferate not merely to gain reproductive advantage, but also simply to survive while pitted against ever-evolving opposing organisms in an ever-changing environment,
- Companies werenât made for this type of change. They werenât made to be flexible. What were they made for? Why do we have such refined and efficient management and behavioral management techniques and have had for decades? Out of the industrial revolution came this insatiable appetite for things. â Product -- And we see this in currently developing countries as well. Take inputs, squeeze incredible efficiency, map processes to cogs in the machine, churn the machine, have utmost repeatable results, and poop out this product at the end of the assembly line. Our companies from top to bottom, from the cogs to the middle managers, to the complex silos and hierarchies has all been efficiently designed for this process. And weâve been good at this for years. Many years. We all have stuff⊠lots of stuff. Iâve got an entire garage full of crap my wife wants me to organize and throw away. Iâve got an iphone. I donât need 5 more of them. We get to the point in our societal maturity where we saturate with stuff. Companies can no longer create the kind of value with just pushing out stuff. They need to be able to create value over and above the stuffâŠ. And also take note.. A lot of the old industrialized sectors like manufacturing and such are quickly becoming commoditized or automated out of existence.
- Quickly lose sight of the big picture, lots of synchronization points, etc Weâve designed for efficiency to create products, but we need to re-think this. We need variability Weâve designed our companies for efficiency. Efficiency is the goal because thatâs what has helped us produce products very reliably and fast. So we create silos, or boxes, and stuff people into those boxes or âareas of specializationâ and tell them to focus on their one thing. The problem with this is two things: They very quickly lose sight of the overall goals and the big picture The interaction points and synchronization points between all of those divisions of responsibility goes up. The more points of communication or synchronization the more changes for failure, bureaucracy, and the more difficult it is to change or solve problems that you werenât originally designed for, This causes all kinds of odd tradeoffs that must be made, further making it different to change or adapt. Example sales/operations, divide by product category or customer alignment.. Etc. This restricts people from thinking. This handcuffs decision making where itâs needed the most: the place where employees have the most information, at the edges of the company. It causes changes to make undesired effects that ripple throughout. Our companies were constructed like machines. Machines do one thing they were built to do. If you want them to do something else, you have to get another machine, or try to adjust or rebuild the machine. This is known as reorganizations, or re-engineering, etc. but companies have to also operate their company while trying to âright size itâ. Machines have their structure built tailored to what they do. Companies grow and change, so they need a structure that allows them to do that. Ultimately, companies are made up of PEOPLE. So how do we organize a company made up of people to grow as the company does, as market conditions change, as economic factors change?
- We need to build into our system the ability to deal with variety. We need to adapt, respond, be agile. Example: Nordstroms employee handbook, only #1 rule - Use best judgement in all situations. There will be no additional rules. (Please feel free to ask your dept manager, store manager, or division general manage any question at any time.)
- The discovery of whatâs important, and the experimentation process leads us to want to find business value. We want to quickly find out the things that donât work and minimize the cost it takes to do these experiments. This transformation is a process, not something that happens over night, and not something you can copy. Youâll even note that each organization is different in how it can go about this process; each needs to balance speed, safety, and business value for itself.
- Keys: Weâve had SOA/Agile/XP/Scrum/ESM/etc Canât know things up front. Need to be agile. Weâve been talking about building agile businesses for a while. At least over last 20 yrs or so weâve been looking at how to build *Software* a bit more agile-likeâŠ. Weâve had the likes of SOA, the Agile manifesto, countless books on Scrum/XP, etc. Now weâre inundated with talks about cloud, devops, microservices etc... Weâve all agreed that âknowing everything up frontâ is really hard if not impossible and that investing ~12-18mo projects to build something ends up being very risky. So we understand this from a technology standpoint⊠but maybe the same is true about our business? And the market? Books like Lean Startup and Lean Enterprise tell us that business value isnât always known up front for 12-18months... So what are we missing?
- If we want flexible, agile, adaptive systems, we need to have an organization that looks like that and encourages it.
- Business Agility!!! Journey ⊠Understand them, Test them, Change them, Different pace â rate of change is key !!! Agile business⊠Before going too far, we should have a definition about what microservices are. When we talk about microservices, we talk about breaking up complicated, potentially really large systems, whatever they may be, into smaller components. We break them into smaller components so we can understand them individually, test them individually, scale them and ultimately change them at a different pace than the rest of the system. You can imagine having to please every master in a monolithic environment can slow/bog things down and inhibit change. Which as we discussed in the beginning is the key here. We need to be able to work on systems that can change with the rest of the business as itâs getting even more competitive and disruptive. One of the keys to this flexibility and ability to change is to focus on autonomy. Systems should be designed to be more autonomous so that changes donât affect other downstream systems, faults donât ripple across into cascading failures etc. The more dependencies we have (on other systems, protocols, shared libraries, databases, etc) the harder it can be to make changes. So we talk about services having and owning their own data, choosing the right technology for their function, and consciously enforcing modularity through APIs and contracts. Autonomy is key here. But autonomy of systems includes autonomy of teams as well. Microservices can be a means to an end for a company serious about investing into their digital experience they provide to customers. Itâs not in and of itself the end goal. Itâs part of a digital transformation that encompasses all parts of the organization.
- SOA optimized for re-use⊠classic cost optimization. Microservices optimizes for speed (potentially at the cost of re-use)
- Remember this slide was asking what you are doing today? Well how about making a big jump forward on this todo list with OpenShift Container Platform?
- Red Hat OpenShift 3.x is a Apache v2 licensed open-source developer self-service platform (OpenShift Origin: https://github.com/openshift/origin) that has been revamped to use Docker and Kubernetes. OpenShift at one point had its own cluster management and orchestration engine, but with the knowledge, simplicity, and power that Kubernetes brings to the world of container cluster management, it would have been silly to try and recreate yet another one. The broader community is converging around Kubernetes and Red Hat is all in with Kubernetes. OpenShift has many features, but of the most important is that it's still native Kubernetes under the covers and supports features many enterprises need role-based access control, out of the box software defined networking, security, logins, developer builds, and many other things.
- Talk about the Open Innovation Labs to help you on your journey to a microservices architectureâŠ