Modernization: The End Of The Heavyweight Era The End Of The Heavyweight Era ... Take a lesson from Domain Driven Design (DDD) ... not in retrospective

Modernization: The End Of The Heavyweight EraWhy The Actor Model Matters for Cloud Infrastructure

WHITE PAPER

MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE

2

Table of Contents

Why Read This Report ................................................................................................................... 3

Key Takeaways .............................................................................................................................. 3Java EE Middleware is the Wrong Approach for Today’s Cloud-Based Infrastructures ..................................................................3

Distributed, Reactive Systems Unlock Higher Cloud ROI ......................................................................................................................3

Java EE Middleware Is A Modernization Mismatch ......................................................................... 4Java EE complexity leads to low development velocity and infrequent releases ...........................................................................4

Java EE is too heavyweight to scale, and too expensive for the cloud ..............................................................................................5

Java EE won’t let you harness ‘data in motion’ .......................................................................................................................................6

Shifting Towards Actor-based Reactive Systems ............................................................................ 8Design distributed systems based on Reactive principles ...................................................................................................................8

Take a lesson from Domain Driven Design (DDD) ...................................................................................................................................9

Prioritize resilience before thinking about elastic scaling in the cloud ........................................................................................... 11

Utilize actors for native distribution, concurrency, supervision, and resilience ........................................................................... 12

Modernizing with the Actor Model ................................................................................................13Enhancing customer engagement with data-driven insights ............................................................................................................14

Unleashing innovation to protect or capture markets ........................................................................................................................14

Improving agility and time to value ........................................................................................................................................................ 15

Reducing compute costs while scaling elastically ............................................................................................................................... 15

Increasing developer happiness and productivity .............................................................................................................................. 16

The Days Of Java EE Heavyweight Middleware Are Ending ............................................................17


3

Why Read This Report

In a world where business models face constant disruption, digital business imperatives are driv-ing architects and technology leaders to embrace modernization to remain competitive. However, traditional application monoliths running on Java EE middleware were not designed with develop-ment agility and cloud elasticity in mind, making them an ill-suited solution for today’s needs.

This report helps architects and technology leaders understand the business impact of mod-ernizing with the actor model to build Reactive systems--systems that are purpose-built for the modern era of multicore cloud computing.

Key Takeaways

Java EE Middleware is the Wrong Approach for Today’s Cloud-Based Infrastructures

Over the years, the use of legacy technologies and expensive Java EE middleware has resulted in the pervasiveness of large, monolithic applications. Enterprises are becoming bogged down with long release cycles and increasingly complex applica-tions, leaving teams unable to achieve a high level of development productivity as well as firefighting production systems that were never designed for cloud infrastructures.

Distributed, Reactive Systems Unlock Higher Cloud ROI

Achieving ROI in the cloud starts with designing dis-tributed architectures and decomposing monoliths into individual, decoupled microservices based on Reactive principles. Reactive systems enable enter-prises to be flexible--able to adapt to complex envi-ronments--and quickly roll out new changes without rigid dependencies and coordination. With the actor model as a foundation, these systems are designed to scale massively at any given moment without compromising infrastructure. Most importantly, they are capable of rapidly identifying, reporting, and self-healing in the face of failure at any system level.


4

Java EE Middleware Is A Modernization Mismatch

“By 2019, fewer than 35% of all new business applications will be deployed in Java EE application servers.”

- Anne Thomas, Distinguished Analyst at Gartner Group

Global 5000 enterprises that never before considered themselves as technology companies are now faced with digital business imperatives that force them to modernize their infrastructure. On the path to becoming a digital, on-demand provider, speed is the ultimate competitive advantage. With technology and business innovation inextricably intertwined, businesses must adapt with greater agility than ever before.

Technology leaders (e.g. Amazon, Microsoft, Google, LinkedIn, etc.) and industry analysts (Gartner, For-rester Research, RedMonk) agree that modern system architecture must embrace a cloud-first strategy to capture the benefits of development agility and cost efficiency. Modern systems need to be optimized for latency and architected for resilience and elasticity. As online consumption continues to grow at an exponential rate, modern systems require a highly flexible infrastructure design that can scale at levels far higher than previous conceptions of peak traffic.

For the majority of use cases, however, the Global 5000 do not have the luxury of starting with a green-field infrastructure such as digital natives LinkedIn, Netflix, or Airbnb. Changes need to be made within existing frameworks to keep pace with new web scale organizations. Yet most organizations have huge investments in legacy Java EE infrastructure, resulting in technical debt and monolithic systems that require modernization in order to reverse the following:

• Poor development agility that causes slow and infrequent releases • Monolithic applications that are difficult to scale and aren’t optimized for cloud infrastructure• The inability to react based on real-time insights and streaming ‘data in motion’

Java EE complexity leads to low development velocity and infrequent releases

For a decade or more, enterprise development teams have built their Java EE projects inside large, mono-lithic application server containers without much regard to the individual lifecycle of their module or component. Hooking into startup and shutdown events was simple, as accessing other components was just an injected instance away. It was comparably easy to map objects into single relational databases or connect to other systems via messaging. One of the greatest advantages of this architecture was transac-tionality, which was synchronous, easy to implement, and simple to visualize and monitor. Projects were released twice per year, had multi-year lifespans, multi-month test cycles, and large teams to manage everything.


5

But those days are now at an end. Due to lack of agility, applications grew enormous, leading to the accu-mulation of technical debt, slower development velocity, and longer release cycles.

› Development team agility is constantly blocked. With no simple development model to sup-port modern systems, the traditional compile-build-deploy cycle for every service cripples pro-ductivity. At best, reusability and componentization in Java EE is achieved by sharing packaged bundles between projects. These designs ultimately rely on a single database schema with sheer project ROI calculated on comparably long production uptimes.

› Big teams and heavy apps create long release cycles. With ongoing maintenance and the con-stant addition of new features, monoliths constantly grow in size. This means that each app has to be created, maintained, and managed by increasingly larger project teams. Team structures are also heavily influenced by these monolithic software architectures, with multi-month test cycles being perhaps the most visible proof. Projects with lifespans longer than five years tend to have huge bugs and feature databases. Since containerless development is impossible, testing is barely qualified--there are no acceptance tests and hardly any written business requirements or identifi-able domains in design and usability.

› Complex code bases and fearful engineers lead to technical debt. Instead of business-driven components, the classical monolith has a very technical design and struggles to keep up with the constant change in business requirements. Production releases often occur only twice a year, and introducing new features or making hot fixes outside of the official production setting process is a risky venture. Upholding the motto: “Never change a running system,” continuous inherited complexity leads to a very cautious update process by engineers who are understandably afraid of breaking anything. And as technical debt increases, enterprises are discovering that licensing models of various vendors force them to continue use of older product versions.

Java EE is too heavyweight to scale, and too expensive for the cloud

From a production perspective, the classical monolith relies on heavyweight infrastructure and rarely scales inside the application server itself. Scaling therefore requires vast engineering resources, making it a clunky, expensive, and inefficient process.

› Monoliths are difficult and expensive to scale. Java EE applications are bound to the thread-per-request model, making it difficult for them to scale to larger numbers of servers. And clustering relies on vendor-specific features because it’s not part of the Java EE specification. Servicing a growing number of users requires the complete replication of the application server stack, includ-ing the underlying infrastructure. With more extensive scaling requirements, the use of vendor-pro-prietary features and clustering options is mandatory for many installations.


6

› Monoliths lead to resource inefficiency. Even with optimizations, scalability is limited to a couple of hundred nodes and can’t be controlled dynamically to serve load peaks without confronting fail-ures. Instead of intelligent, dynamic scaling, monoliths must always be prepared for traffic peaks. This makes scaling and calculating infrastructure requirements difficult, leading to a lot of unused compute power that is only activated for rare high demand occasions. And when things go wrong, Java EE has no built-in resilience mechanisms--one component failure usually brings down the entire application.

Java EE won’t let you harness ‘data in motion’

Since its invention, the way people use the internet has fundamentally changed. A tidal wave of connect-ed devices, sensors, and intelligent home appliances has caused demands to grow exponentially.

In 1995, less than 1% of the world population had an internet connection. Today it’s around 40%. The number of internet users increased tenfold from 1999 to 2013. The world’s billionth user logged on in 2005, and by 2010, that number had doubled to two billion. In 2014, the internet reached three billion users. (source: http://www.internetlivestats.com/internet-users/). In response to this rampant growth, the requirements for modern applications have drastically changed.

› Java EE is not built for Fast Data. Instead of operating on data that rests in a centralized relation-al database (RDBMS), modern software increasingly relies on data in near real-time. While there will continue to be a need for batch-mode processing for some services, the ability to work with time-sensitive data presents an enormous competitive business advantage. Yet Java EE has no native support for streaming “data in motion,” and the tools provided (JDBC and JPA) are synchro-nous and blocking, allowing only one query at a time per connection.


7

› Java EE lacks flexibility to move fast. Modern reporting and incident analysis has to happen while the data streams into the application, not in retrospective. With high flexibility now a require-ment rather than a “nice to have,” production systems must be equipped to resolve issues that weren’t considered or even relevant when their initial version was put into production.


8

Shifting Towards Actor-based Reactive Systems

“The actor model [is seeing] renewed interest as cloud concurrency challenges grow.”

- Jeffrey Hammond, Principal Analyst at Forrester Research

To address all the shortcomings of monolithic Java EE applications and the heavyweight middleware and infrastructure needed to run them, developers must shift their thinking. Both systems and organizations themselves must increase flexibility, adapt to complex environments, quickly roll out new changes with-out rigid dependencies and coordination, know how and when to behave in certain ways, scale massively at any given moment without compromising infrastructure, and most importantly, be able to rapidly identify, isolate, and self-heal in the face of failure at any level. The steps for achieving these goals include:

1. Design distributed systems based on Reactive principles2. On the path to Microservices, take a lesson from Domain Driven Design (DDD)3. Prioritize resilience before thinking about scaling elastically in the cloud4. Utilize the proven actor model to achieve native distribution, concurrency, supervision,

and resilience

Design distributed systems based on Reactive principles

Designers need to build systems for flexibility and resiliency, not just efficiency and robustness. This ne-cessitates the redesign of existing Java EE applications into more flexible modules that are self-contained, autonomous, and can be scaled independently, as they are responsible for their own business context from individual features down to the relevant data. These are called Reactive systems.

To make it easier for business leaders, IT professionals, and third-party vendors to innovate and collab-orate around these new systems, a common vocabulary was established in the Reactive Manifesto1 to cover these requirements: Reactive systems are Message-Driven, Resilient, Elastic, and Responsive.

1 Spearheaded in 2013 by Lightbend CTO/Co-founder and the inventor of Akka, Jonas Bonér, the Reactive Manifesto has been signed by over 15,000 people and translated into 11 languages


9

responsive

elastic resilient

message-driven

Value

Form

Means

› Message-driven means more than just non-blocking I/O. Reactive systems at their foundation are powered by asynchronous, non-blocking, message-driven communication. This enables super-vision, isolation, and replication of failed processes.

› Resilience goes further than fault tolerance. The ability to self-heal in an automated and pre-dictable way is treated as part of the full service/application lifecycle and made possible by a message-driven approach to communication.

› Elasticity means efficient, cost-conscious scalability. A message-driven foundation enables a level of indirection and loose coupling. This helps create systems that can boost performance by scaling out, as well as up, across all physical and cloud infrastructure during busy times, and lower costs by dynamically scaling in/down during slow times.

› Responsive systems always serve customers. Reactive systems provide a consistently respon-sive user experience that is highly available, never fails during busy times, and isn’t susceptible to blocked processes and cascading failures.

Take a lesson from Domain Driven Design (DDD)

Rather than thinking of Microservices Architecture (MSA) as service-oriented architecture (SOA) 2.0, de-velopers now have the Reactive Manifesto to help them apply the principles of Reactive systems to real world domains. The requirements of MSA can best be identified with the help of Domain Driven Design


10

(DDD), an architectural principle that recommends designing systems to reflect real world domains, con-sidering the elements, behavior, and interactions between business domains.

Microservices operate on principles similar to those of DDD. Each microservice owns its data and must be responsible for a specific feature or functionality, and be able to work together as a system to form an aggregation of cohesive functionality. A good rule of thumb is to gather services that change for the same reason while separating those services that can change for a different reason. This can be achieved by designing systems that:

› Use encapsulation to improve flexibility. Microservices must encapsulate all internal imple-mentation details so that external systems utilizing them in the cloud or on-premise never need to worry about the internals. Encapsulation reduces complexity and enhances flexibility of the system, making it more amenable to changes.

› Apply loose coupling to avoid the cascade effect. The changes to a single microservice should have no negative impact on other services. As synchronous communication introduces a host of interrelated dependencies, this principle aligns with the message-driven communication approach to distributed systems by enforcing asynchronous, non-blocking communication between micros-ervices. As per SOA, RESTful APIs are more suitable than Java RMI, as the latter enforces a technol-ogy on other system components.

› Separate domains of concern to reduce complexity. Creating microservices based on distinct functions with zero overlap of concerns with other components lets designers reduce the com-plexity of interaction between services. While it is important for each microservice to own its data, there is considerable flexibility in how that data is stored. Of course, the data may be stored in a traditional database. However, it is also common for some microservice implementations to store data into multiple databases. For example, store data in an RDB for flexible queries and also in


11

ElasticSearch to provide more advanced search options. Another common data storage approach is to save all data change requests in an event log and also store the data in a more queryable form in one or more databases. This approach is known as Event Sourcing and CQRS (Command Query Responsibility Segregation). The advantage here is that these other data storage options offer greater flexibility for how data is stored and how it can be retrieved. These alternatives provide much more flexibility for scaling and resilience.

Prioritize resilience before thinking about elastic scaling in the cloud

Most applications are designed and developed for blue skies. But all software across all time has failed and will continue to fail. Today’s applications therefore must be designed with the inevitability of failure in mind.

With cloud-based microservices architectures, things are even more complex: these applications are composed of a large number of individual services, adding a level of complexity that touches all relevant parts of an application in order to measure availability and recover from failures.

These new requirements force designers to reconsider how they incorporate error handling and fault tolerance into applications. Modern applications must be resilient on all levels, not just a few. Reactive systems therefore place a critical focus on resilience, which enables systems to self-heal automatically and adopt a “let It crash” philosophy.

The key to achieving this is message-driven service interaction, which automatically provides the core building blocks that enable systems to be resilient against failures at many different levels. In turn, these building blocks serve as a rock-solid foundation that is capable of scaling in and out elastically across all system resources.

› Automate supervision to minimize human intervention. The goal for design of resilience against failures is to minimize human intervention. Supervision--the ability to identify successful or unsuccessful task completion across the entire system--is at the core of system performance, en-durance, and security. Supervision based on a message-driven approach enables location trans-parency, so that processes can run and interact on completely different cluster nodes as easily as in-process on the same VM.

› Isolate and contain failures to enable self-healing. When isolation is in place, systems can separate different types of work based on a number of factors, like the risk of failure, performance characteristics, CPU and memory usage, etc. Failure in one isolated component won’t impact the re-sponsiveness of the overall system and the failing component will have a chance to heal. A dedicated separate error channel allows redirection of an error rather than just throwing it back to the caller.

› Master resilience and elasticity to achieve system responsiveness. Modern applications must be resilient at their core in order to scale and remain responsive under a variety of real-world, less than ideal conditions. The result is a consistently responsive system ready for business.


12

Utilize actors for native distribution, concurrency, supervision, and resilience

Traditional “sometimes asynchronous” platforms like Java EE are missing a key requirement for building distributed systems. Microservices architectures must be message-driven and distributed from the start, from the lowest level protocols extending out into third-party APIs and scaling elastically across clusters. Distribution is not something that can be added on later, but is a critical, foundational design element that must be in place from the beginning.

Enter the actor model. First conceived in 1973 by Carl Hewitt, the actor model is a message-driven approach to concurrent computation intending to provide “the prospect of highly parallel computing machines consisting of dozens, hundreds, or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communi-cations network.” (William Clinger (June 1981). “Foundations of Actor Semantics”. Mathematics Doctoral Dissertation. MIT.)


13

Modernizing with the Actor Model

“For the first time in our history, we faced no downtime on Black Friday.”

- Walmart

Akka is an actor-based message-driven runtime for managing concurrency, elasticity, and resilience on the JVM with support for both Java and Scala. By applying the proven actor model to the JVM, Akka is distributed by default to serve the evolved needs of microservices architectures, providing distribution, concurrency, supervision, and resilience. Critically, Akka allows designers to:

› Focus on the business logic, not low-level protocols. Not only do developers need to be able to take advantage of multiple cores on a single machine, at a certain point they must also utilize clus-ters of machines themselves. Distributed by default and based on the proven actor model, Akka provides managed concurrency out-of-the-box so that teams can focus on the system’s business logic rather than manually wiring together complex, low-level protocols.

› Eliminate bottlenecks and single points of failure. Reactive applications are difficult to build within thread-based frameworks because of how hard it is to scale out an application reliably based on shared mutable state, threads, and locks. When designed incorrectly, system perfor-mance and availability suffer huge losses. Akka actors employ asynchronous, non-blocking, mes-sage-driven communication with a secure supervision model. This allows Akka to easily share work across all infrastructure resources, resulting highly resilient, elastically scalable systems.

› Realize true ROI from investing in cloud infrastructure. Shared mutable state also makes it dif-ficult, though not impossible, to scale up. Ensuring thread safety is complicated, and performance penalties associated with over-engineering for thread safety are severe. With the lightweight actor model, Akka is ideal for cloud and hybrid-cloud deployments, keeping infrastructure costs under control while maintaining a high level of responsiveness to serve customers.

To address the business challenges of modernization, many of the most admired brands around the globe are transforming their businesses with Lightbend, engaging billions of users every day through software that is disrupting their markets. Lightbend provides the leading Reactive application development platform on the JVM for building distributed applications and modernizing aging infrastructures. Using microservices and fast data on a message-driven runtime, Reactive Platform applications are able to scale effortlessly on multicore and cloud computing architectures, avoiding many common Java EE pitfalls.


14

Supporting both Java and Scala, Lightbend Platforms include the Akka message-driven runtime, Lagom microservice framework, Play web framework, and Scala programming language. With Lightbend, de-velopment teams can deliver highly responsive user experiences backed by a resilient, message-driven application stack.

Enhancing customer engagement with data-driven insights

For many enterprises, using data-driven insights to deepen customer engagement over web, mobile and IoT applications is a focal point of digital transformation. Consequently, architectures are shifting from batch to streaming.

› Microservice and data architectures are unifying. The demands for availability, scalability, and resilience is forcing Fast Data architectures to become like microservice architectures. Conversely, successful organizations building microservices find their data needs grow with their organization. Hence, there is a unification happening between data and microservice architectures that the actor model is uniquely capable of serving.

› Case Study: Delivering 30-second personalized offers at 100x traffic peaks. At online gaming leader William Hill, personalized offers may only be valid for thirty seconds and must per-form perfectly when traffic regularly spikes by 100x. READ MORE

Unleashing innovation to protect or capture markets

Many digital transformation initiatives at large enterprises are being sparked by either The Innovator’s Dilemma in which market leader successes and capabilities have actually become obstacles to seizing the next wave of innovation, or the Reinventors in which successful companies are using a key asset to capture a new market.

› Empowering developers to innovate. Lightbend technologies based on the actor model make developers feel empowered by making things that used to be very hard quite easy and straightfor-ward, allowing them to do things they didn’t dare before. Actors embrace the reality of unplanned errors and adopt a pragmatic “Let It Crash” philosophy using supervision and self-healing to ensure impacted components are reset to a stable state and restarted upon failure.

› Case Study: Achieving 5 consecutive quarters of member growth. Today with its micro-services architecture, Weight Watchers has become a nimble development organization that innovates new customer services based on real-time data and integration with various devices, resulting in five consecutive quarters of recruitment growth. READ MORE


15

Improving agility and time to value

In a world where business models face constant disruption, your digital transformation initiative is likely driving you to embrace speed to remain competitive. However, traditional application monoliths running on Java EE middleware were not designed with development agility in mind. With no simple development model to support modern systems, the traditional compile-build-deploy cycle for every service cripples productivity.

› Work autonomously, deliver continuously. The actor-based, asynchronous foundation of Light-bend Platforms supports the design of Reactive systems, which reduce dependencies between components and enable feature teams to work autonomously and deliver continuously, accelerat-ing time to value by 2x to 3x.

› Case Study: Propagating changes 700% faster. MoneySuperMarket Group (MSM), the holding company behind three of the UK’s most popular comparison shopping sites is propagating new fea-tures 700% faster, dramatically accelerating the time to revenue. READ MORE

Reducing compute costs while scaling elastically

Nearly every digital transformation initiative includes a cloud strategy. And, nearly every industry analyst will tell you, if you want to take advantage of the cloud, you can’t lift and shift. Your applications need to be architected for the cloud. In fact, Gartner is recommending you design every new application to be cloud-native, even if you plan to run it on-premise.

› Because our Platforms are actor-based and use asynchronous message passing, they more dense-ly utilize commodity hardware compared with traditional systems bloated by locked threads. Plus, the Platforms scale up and out effortlessly on multi-core and cloud computing architectures. They handle bursty traffic with ease, without requiring hardware over provisioning, so you can reap the financial benefits of elasticity. The added resilience, and cost savings, are huge.

› Case study: Saving 50% on infrastructure with no downtime. After experiencing a horrific—and very public—downtime, Walmart Canada modernized its e-commerce platform, shaving 50% off infrastructure costs, and achieving unprecedented resilience. READ MORE


16

Increasing developer happiness and productivity

With your digital transformation, a tremendous amount of development lays ahead. If your developers are hamstrung by old tools, it will be nearly impossible to keep your project on track and your top talent engaged.

› Making it easier, and faster, to build distributed systems. Because the actor-model is at the heart of our application development platform, it alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent, parallel and distributed systems.

› Case Study: Boosting deployment frequency by 400%. A modern Reactive development model that emphasizes proper service isolation has allowed developers at Norwegian Cruise Lines to continually roll out new features and bug fixes and deploy 400% more frequently. READ MORE


17

The Days Of Java EE Heavyweight Middleware Are Ending

“Our applications are able to serve over a billion hits a day with as little as 8 VMs and 2 vCPU each.”

- PayPal

After a decade or more of building Java EE monoliths that are slow to evolve, complicated to release, and ex-pensive to maintain, modern enterprises are looking to new system architectures for running their business.

The Java EE heavyweight object-oriented method of software development is ill-suited to the always-on, real-time nature of cloud computing. To achieve the full business benefits offered by the cloud, today’s systems must be lean, flexible, and Reactive. Lightbend helps developers create applications that are responsive, resilient, flexible, and message-driven. Built on a foundation of Domain Driven Design and based on actors rather than objects, Lightbend provides the perfect architecture for creating powerful, adaptable applications that thrive in the cloud.

CONTACT US

Lightbend (Twitter: @Lightbend) provides the leading Reactive application development platform for building distributed applications and modernizing aging infrastructures. Using microservices and fast data on a message-driven runtime, enterprise applications scale effortlessly on multi-core and cloud computing architectures. Many of the most admired brands around the globe are transforming their businesses with our platform, engaging billions of users every day through software that is changing the world.

Lightbend, Inc. 625 Market Street, 10th Floor, San Francisco, CA 94105 | www.lightbend.com

Your business needs to modernize. Is the Lightbend application development platform the right solution?

Let’s talk and find out.

Documents

Modernization: The End Of The Heavyweight Era The End Of The Heavyweight Era ... Take a lesson from Domain Driven Design (DDD) ... not in retrospective