Emad has spent the past 25 years in various software engineering positions involving software development of application platforms and distributed systems for various industries such as finance, health, IT, and heavy industry – in various international locations. Emad is currently the Sr. Director and Chief Technologist of Application Platforms with Office of the CTO at VMware, focusing on building hybrid cloud distributed runtimes that are application aware.
There is no doubt that much debate and opinion exists in our industry as to what really is a cloud native app platform! Regardless of what your definition is, it is certain that we simply don't have time to re-write all of the second generation monolithic apps, but yet we must modernize at the same time. With this reality in mind, I begin the discussion of how to build platforms that are both 3rd generation and 2nd generation capable while delivering feasible enterprise application platforms.
As for the cloud native movement, it is important to understand the elements of this rapidly moving phenomenon through our industry, a phenomenon of building platforms, not just business logic software but infrastructure as software. I humbly believe that the drive towards these platform solutions is due to the following fact: approximately half of new applications fail to meet their performance objectives, and almost all of these have 2.x more cloud capacity provisioned than what is actually needed. As developers we live with this fact every day, always chasing performance and feasible scalability, but never actually cementing it into a scientific equation where it is predictable, but rather it has always been trial based, and heavily prone to error. As a result we find ourselves delving with some interesting platforming patterns of this decade, and unfortunately we are lead to believe that such patterns as Microservices, 3rd platforms, cloud native, and 12factor are mainly a change in coding patterns, to the contrary – these patterns reveal a much more deep shift in the way developers view and consume infrastructure. In fact these patterns represent a major change in “deployment” approach, a change in how we deploy and structure code artifacts within applications runtimes, and how those application runtimes can leverage the underlying cloud capacity. These patterns are not code design patterns, but rather platform engineering patterns, with a drive to using APIs/Software to define application platform policies to manage scalability, availability and performance in a predictable manner. In this session I will briefly inspect platform patterns that we built over the last decade, and the ones we are building for the next decade. The main objective of the session will be to layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up both manually and dynamically as needed within your software defined platform. Which are key ingredients for knowing how to run 2nd and 3rd gen application platforms at the same time under one platform.
There is no doubt that much debate and opinion exists in our industry as to what really is a cloud native app platform! Regardless of what your definition is, it is certain that we simply don't have time to re-write all of the second generation monolithic apps, but yet we must modernize at the same time. With this reality in mind, I begin the discussion of how to build platforms that are both 3rd generation and 2nd generation capable while delivering feasible enterprise application platforms.
As for the cloud native movement, it is important to understand the elements of this rapidly moving phenomenon through our industry, a phenomenon of building platforms, not just business logic software but infrastructure as software. I humbly believe that the drive towards these platform solutions is due to the following fact: approximately half of new applications fail to meet their performance objectives, and almost all of these have 2.x more cloud capacity provisioned than what is actually needed. As developers we live with this fact every day, always chasing performance and feasible scalability, but never actually cementing it into a scientific equation where it is predictable, but rather it has always been trial based, and heavily prone to error. As a result we find ourselves delving with some interesting platforming patterns of this decade, and unfortunately we are lead to believe that such patterns as Microservices, 3rd platforms, cloud native, and 12factor are mainly a change in coding patterns, to the contrary – these patterns reveal a much more deep shift in the way developers view and consume infrastructure. In fact these patterns represent a major change in “deployment” approach, a change in how we deploy and structure code artifacts within applications runtimes, and how those application runtimes can leverage the underlying cloud capacity. These patterns are not code design patterns, but rather platform engineering patterns, with a drive to using APIs/Software to define application platform policies to manage scalability, availability and performance in a predictable manner. In this session I will briefly inspect platform patterns that we built over the last decade, and the ones we are building for the next decade. The main objective of the session will be to layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up both manually and dynamically as needed within your software defined platform. Which are key ingredients for knowing how to run 2nd and 3rd gen application platforms at the same time under one platform.
Virtualizing and Tuning Large-Scale Java Platforms
Technical best practices and real-world tips for optimizing enterprise Java applications on VMware vSphere®
Enterprises no longer ask, “Can Java be virtualized”? Today, they ask, “Just how large can we scale virtualized Java application platforms, and just how efficiently can we tune them?” Now, the leading expert on Java virtualization answers these questions, offering detailed technical information you can apply in any production or QA/test environment.
Emad Benjamin has spent nine years virtualizing VMware’s own enterprise Java applications and working with nearly 300 leading VMware customers on projects of all types and sizes—from 100 JVMs to 10,000+, with heaps from 1GB to 360GB, and including massive big-data applications built on clustered JVMs. Reflecting all this experience, he shows you how to successfully size and tune any Java workload.
This reference and performance “cookbook” identifies high-value optimization opportunities that apply to physical environments, virtual environments, or both. You learn how to rationalize and scale existing Java infrastructure, modernize architecture for new applications, and systematically benchmark and improve every aspect of virtualized Java performance. Throughout, Benjamin offers real performance studies, specific advice, and “from-the-trenches” insights into monitoring and troubleshooting.
Coverage includes
--Performance issues associated with large-scale Java platforms, including consolidation, elasticity, and flexibility
--Technical considerations arising from theoretical and practical limits of Java platforms
--Building horizontal in-memory databases with VMware vFabric SQLFire to improve scalability and response times
--Tuning large-scale Java using throughput/parallel GC and Concurrent Mark and Sweep (CMS) techniques
--Designing and sizing a new virtualized Java environment
--Designing and sizing new large-scale Java platforms when migrating from physical to virtualized deployments
--Designing and sizing large-scale Java platforms for latency-sensitive in-memory databases
--Real-world performance studies: SQLFire vs. RDBMS, Spring-based Java web apps, vFabric SpringTrader, application tiers, data tiers, and more
--Performance differences between ESXi3, 4.1, and 5
--Best-practice considerations for each type of workload: architecture, performance, design, sizing, and high availability
--Identifying bottlenecks in the load balancer, web server, Java application server, or DB Server tiers
--Advanced vSphere Java performance troubleshooting with esxtop
--Performance FAQs: answers to specific questions enterprise customers have asked