Dormain Drewitz at SpringOne 2020
•0 likes•303 views
Download to read offline
Report
SpringOne 2020 Dormain Drewitz, Director, Product Marketing, VMware
Recommended
More Related Content
More from VMware Tanzu
More from VMware Tanzu(20)
Recently uploaded
Recently uploaded(20)
Dormain Drewitz at SpringOne 2020
- 1. ©2020 VMware, Inc.
- 2. ©2020 VMware, Inc. Photo by Christa Dodoo on Unsplash Photo by Kelly Sikkema on Unsplash
- 3. ©2020 VMware, Inc. Photo by Alexander Andrews on Unsplash
- 4. ©2020 VMware, Inc.
- 5. ©2020 VMware, Inc. Photo by David Becker on Unsplash
- 6. ©2020 VMware, Inc.
- 7. ©2020 VMware, Inc.Photo by Saffu on Unsplash v
- 8. ©2020 VMware, Inc.Photo by Saffu on Unsplash Photo by Henry & Co. on Unsplash
- 9. ©2020 VMware, Inc. Photo by Darío Méndez on UnsplashPhoto by Saffu on Unsplash Photo by Henry & Co. on Unsplash
- 10. ©2020 VMware, Inc. Photo by Darío Méndez on UnsplashPhoto by Saffu on Unsplash Photo by Henry & Co. on Unsplash Photo by ian dooley on Unsplash
- 11. ©2020 VMware, Inc. Piet Mondrian / Public domain
- 12. ©2020 VMware, Inc. lienyuan lee / CC BY (https://creativecommons.org/licenses/by/3.0)
- 13. ©2020 VMware, Inc. Deferring application nature
- 14. ©2020 VMware, Inc.
- 15. ©2020 VMware, Inc.
- 16. ©2020 VMware, Inc. <Madhura’s spotlight>
- 17. ©2020 VMware, Inc.
- 18. ©2020 VMware, Inc. <Sebastien’s spotlight>
- 19. ©2020 VMware, Inc.
- 20. ©2020 VMware, Inc. <Oleg’s spotlight>
- 21. ©2020 VMware, Inc.
- 22. ©2020 VMware, Inc.
- 23. ©2020 VMware, Inc.
- 24. ©2020 VMware, Inc. <Ilaya’s spotlight>
- 25. ©2020 VMware, Inc.
Editor's Notes
- Thanks Bryan and Ben! One thing technology and humanity have in common is that they are never standing still. As technology advances, the choices we have in developing applications evolve.
- The promise of modernization is as much for existing applications as it is for new, so-called “greenfield” applications
- It’s funny the way history changes course sometimes. Whether it’s a meteor out of the sky, a bacteria in the fleas on rats—or an invisible virus—sometimes something new comes along and changes the economics of the way things get done. Containers are a little bit like that. We’ve known about service-oriented patterns for decades. We’ve always wanted to modernize applications to be lighter weight for a long time. But containers—and Kubernetes—came along and changed the economics of modernization and how we actually build and run microservices.
- Of course, the real challenge is finding the willingness to change what we’re already doing… It’s humbling and it’s hard and uncomfortable.
- Whether you do that work or not, the world keeps turning. Your competitors keep shipping. Nothing stands still.
- So, now that the world—that technology—has evolved—the juggernaut of Kubernetes has made landfall, leaving a wake up and down the stack—what are the challenges facing developers in the enterprise? This is by no means an exhaustive list, but here are four that stand out:
- First, faster startups to enable new workload styles like functions as well as responsive autoscaling of applications to handle load spikes.
- Second, distinction and support for long and short running applications, which have unique implications for restarts (the so-called 1-factor applications) and monitoring
- Third, being able to scale-to-zero to allow for better resource utilization and energy savings, as well as financial savings, as you pay-only-when-used
- Finally, lowering the memory footprint for running multiple micro-services instances. This is one of those trade-offs we face when we breakup a single monolith into many microservices. These are some of the challenges raised by modern architectures, but do they only help with so-called modern architectures and applications?
- We’re constantly redefining what “modern” means anyway. Are microservices the holy grail of modern architecture? When you look at these challenges, microservices that “do one thing and one thing well” certainly stand to benefit… but what about existing applications packaged as native images so that they start instantly? That seems like modernization in action, too…
- As we heard from Juergen, Spring is always embracing this evolving technology landscape while looking ahead to new applications, but not losing sight of existing applications
- Joining me today are four members of the Spring team to take us through an evolving set of capabilities for Spring developers to use in building new, modern apps, and modernize existing applications. You’ll hear about: Packaging your application as container Compiling new and existing applications into a native executables Optimizing the cost of the Cloud hosting of your microservices Using new programming models such as reactive versus imperative or functions versus webapps Pluggable activation and invocation models that allow the same set of functional workloads to be exposed as different application styles, such as REST, Messaging and more. By doing so you are effectively deferring the nature of the application to the assembly and packaging.
- But first... Let’s talk about 1543. Because that’s why you’re all here, right?!?! Okay, okay, but indulge me for a moment because I promise this is relevant to our first Spring spotlight In 1543, Henry VIII of England got married for a sixth time, the Ottomans captured key cities in Hungary, and a Polish mathematician published an argument that debunked the long-standing model that the earth was the center of the universe.
- Copernicus’ theory of heliocentricity literally changed the presumed center of the universe. These charts may look similar at a glance, but there’s an important difference. Look closely at what’s in the center. It’s a lot like what we’re seeing in the Spring Boot world today. And to tell us more about the changing center of the universe, in Spring terms, I’m pleased to introduce Madhura Bhave, Software Engineer for Spring Boot. Image sources: Aristotle / Public domain: https://commons.wikimedia.org/wiki/File:Aristotelian_Universe.jpg By Copernican_heliocentrism_diagram.jpg: Own work from Copernicus 1543derivative work: Professor marginalia (talk) - Copernican_heliocentrism_diagram.jpg, Public Domain, https://commons.wikimedia.org/w/index.php?curid=12353176 https://en.wikipedia.org/wiki/Copernican_heliocentrism#/media/File:Copernican_heliocentrism_diagram-2.jpg
- Thanks, Madhura! So, you saw how Spring Boot is making it easier to package up your Spring application into a container. That’s useful. Containers, of course, are lovely because you don’t need a full operating system in the image, making them lighter weight. So, what if we took that approach up to the JVM layer itself? To tell us a little more about where Spring is going with respect to so-called “native executables”, please welcome Spring framework committer, Sebastien Deleuze
- Thanks, Sebastien! Exciting stuff! There is definitely room for faster start times and lower memory consumption in existing applications, but in some cases it’s almost required for some newer architectural patterns. It all comes down to changing the economics to unlock these innovative new patterns. Functions and serverless patterns are a great example of where those fast start up times are really useful. Scale to zero becomes a practical option. Here to tell us more about how Spring is enabling Java developers to write functions so much more efficiently is Spring engineer, Oleg Zhurakousky… but first, he’s going to talk about one of my favorite topics (besides medieval European history): ice-cream
- Thank you, Oleg! Who’s ready to write some functions?
- Did anyone else feel like there was a serious Oprah moment when he let all these different apps activate the same function? Just think: You can have your own Oprah moment writing Spring Cloud Functions. Look under your chair, because you have a function under there just waiting to be activated.
- Okay, okay, enough jokey-joke time. In all seriousness, something we see a lot of in functions is some kind of data processing. It’s a super common use case: new data triggers a function, which spins up to process it, and then needs to hand the output off… perhaps to another function or service. The result of one function is often input to another and so on. As we think about all the novel ways of using data that Ajay referred to this morning—AI and machine learning and IoT use cases—and how to *actually* build those data-driven pieces of functionality into applications, we’re going to need to support more of these event-driven architectures. The good news is: Spring totally lets you do this. The challenge is: how do we orchestrate LOTS of these messaging-driven functions, some of which need to share streams of data? Here to tell us more about that is Spring Software engineer, Ilaya Gopinathan.
- Thanks, Ilaya! Folks, thank you for taking this journey with me through these evolutions in Spring that are opening up new patterns and use cases—as well as ways to improve and modernize existing applications. Be sure to check out the breakout sessions on each of these topics to go deeper. Back to you Ben and Bryan!