IT training white paper modernization why the actor model matters khotailieu

WHITE PAPER

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


Table of Contents
Why Read This Report.................................................................................................................... 3
Key Takeaways............................................................................................................................... 3
Java 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.......................................................................... 4
Java 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............................................................................. 8
Design 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.................................................................................................13
Enhancing 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

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

2


Why Read This Report

Key Takeaways

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

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

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

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 applications, 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 distributed architectures and decomposing monoliths
into individual, decoupled microservices based on
Reactive principles. Reactive systems enable enterprises to be flexible--able to adapt to complex environments--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.

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

3


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, Forrester 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 greenfield 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, monolithic 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 transactionality, 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.
MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA
WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE

4

But those days are now at an end. Due to lack of agility, applications grew enormous, leading to the accumulation 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 productivity. 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 identifiable 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, including the underlying infrastructure. With more extensive scaling requirements, the use of vendor-proprietary features and clustering options is mandatory for many installations.

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

5


›› 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 failures. 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 connected 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: 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 relational 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 synchronous and blocking, allowing only one query at a time per connection.

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

6


›› 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 requirement 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.

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

7


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 without 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 principles
2. On the path to Microservices, take a lesson from Domain Driven Design (DDD)
3. Prioritize resilience before thinking about scaling elastically in the cloud
4. 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 necessitates 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 collaborate 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

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

8


Value

Form

Means

responsive

elastic

resilient

message-driven

›› 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 supervision, isolation, and replication of failed processes.

›› Resilience goes further than fault tolerance. The ability to self-heal in an automated and predictable 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 responsive 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, developers 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

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

9

(DDD), an architectural principle that recommends designing systems to reflect real world domains, considering 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 microservices. As per SOA, RESTful APIs are more suitable than Java RMI, as the latter enforces a technology 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 complexity 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

MODERNIZATION: THE END OF THE HEAVYWEIGHT ERA

WHY THE ACTOR MODEL MATTERS FOR CLOUD INFRASTRUCTURE

10


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, endurance, and security. Supervision based on a message-driven approach enables location transparency, 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 responsiveness 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.

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

11


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 communications network.” (William Clinger (June 1981). “Foundations of Actor Semantics”. Mathematics Doctoral

Dissertation. MIT.)

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

12


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 clusters 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 performance and availability suffer huge losses. Akka actors employ asynchronous, non-blocking, message-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 difficult, 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.

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

13


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, development 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 perform 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 straightforward, 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

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

14


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, accelerating 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 features 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 densely 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

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

15


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

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

16


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 expensive 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.

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

17


Your business needs to
modernize. Is the Lightbend
application development
platform the right solution?
Let’s talk and find out.
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