Using containers to build a microservices architecture
•Transferir como PPTX, PDF•
1 gostou•1,832 visualizações
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
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Using containers to build a microservices architecture
Semelhante a Using containers to build a microservices architecture (20)
Mais de Eric D. Schabell
Mais de Eric D. Schabell (20)
Último
Último (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
Notas do Editor
- 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…