Running WebSphere Liberty Profile or Tomcat in Cloud Foundry

Why should you chose to run your apps on a plain vanilla Tomcat/Jetty/Undertow servers with the Spring Framework instead of running on WebSphere Liberty Profile or any proprietary app server.

• Oracle has stopped investing in JavaEE. Java-Gaurdians. Java EE innovation driven through the JCP process is driven to a complete halt thanks to lack of investment by its major supporters and Oracle hosting the Java EE standard  hostage with the proprietary TCK accessible only to Oracle and corporate licenses. [reboot]. Meanwhile innovation in the Spring community has taken off. 
• Don't take my word on it. Read the analyst Stephen O' Grady's opinion on Spring Boot ... Better than ten years removed from the initial release of Rails, it seems strange to be writing about the “new” emphasis on projects intended to simplify the boostrapping process. But in spite of the more recent successes of projects like Bootstrap and Spring Boot, such projects are not the first priority for most technical communities. Perhaps because of the tendency to admire elegant solutions to problems of great difficulty, frameworks and on ramps to new community entrants tend to be an afterthought. In spite of this, they frequently prove to be immensely popular, because in any given community the people who know little about it far outnumber the experts. Even in situations, then, when the boot-oriented project and its opinions are outgrown, boot-style projects can have immense value simply because they widen the funnel of incoming developers. 
• Thoughtworks technology radar now recommends Spring Boot as an ADOPT technology.  A lot of work has gone into Spring Boot to reduce complexity and dependencies, which largely alleviates our previous reservations. If you live in a Spring ecosystem and are moving to microservices, Spring Boot is now the obvious choice. For those not in Springland, Dropwizard is also worthy of serious consideration.
• Developing applications using the full feature set of the WebSphere Liberty Profile will result in your application being non-portable to other app servers or migration from WebSphere Classic versions to the Liberty Profile. Furthermore you are offloading the control of your applications features to the app-server. Using Spring and vendored frameworks instead of provided dependencies at runtime yields control back to the application leading to a deterministic set of compile and runtime dependencies. Packaging apps with Spring lead to immutable artifacts. 
• Idiomatic Applications written with the Spring Framework and Spring Boot on Pivotal Cloud Foundry running on a plain vanilla app server written in an idiomatic fashion are inherently 15 factor cloud native app. The applications are production-ready from the get-go. 
• Organizations are now comfortable running business critical applications in production. Take a look at a recent Java Application Server survey report from Plumbr where the Tomcat installation base exceeded the 50% threshold for the second year in a row. The 58.22% share of the pie left no question about the winner. 

Multi-line Java stack traces out of order in Logstash and Splunk

Do you have customers frustrated by getting multi-line Java stack traces out of order? We're working on a clean solution in our enhanced metrics work, but here is a workaround courtesy @DavidLaing .

With the Java Logback library you can do this by adding 

"%replace(%xException){'\n','\u2028'}%nopex" 

to your logging config [1] , and then use the following logstash conf.[2]

Replace the unicode newline character \u2028 with \n, which Kibana will display as a new line.

mutate {
  gsub => [ "[@message]", '\u2028', "

"]

^^^ Seems that passing a string with an actual newline in it is the only way to make gsub work

}

[1] https://github.com/dpinto-pivotal/cf-SpringBootTrader-config/blob/master/application.yml#L12

[2] https://github.com/cloudfoundry-community/logsearch-for-cloudfoundry/blob/master/src/logsearch-config/src/logstash-filters/snippets/firehose.conf#L60-L64

Top 10 KPIs Cloud Foundry

The cloud foundry firehose and syslog streams generate tons of metrics and logs. What should a busy devops engineer look at ? My colleague Ford Donald put this awesome list of the top 10 KPIs of Cloud Foundry.

+----------------------------------+---------+--------------------+
| KPI                              | Description
+----------------------------------+---------+--------------------+
| rep.capacityRemainingMemory      | Available cell memory (sum for all cells)
| rep.capacityRemainingDisk        | Available cell disk (sum for all cells)
| bbs.LRPsRunning                  | Equivalent to # apps running
| bbs.RequestLatency               | CF of API is slow if this rises
| bbs.ConvergingLRPduration        | Apps or staging crashing if this rises
| stager.StagingRequestFailed      | Indicates bad app or buildpack pushes
| auctioneer.LRPauctionsFailed     | CF can’t place an app (out of container space)
| router.totalRoutes               | Size in routes of a PCF install (indicates uptake)
| router.requests                  | Tracks traffic flow thru a PCF
| bosh.healthmonitor.system.healthy| Indicates BOSH/VM health
+----------------------------------+---------+--------------------+

New PCF v1.10 "Monitoring PCF" docs section went live!  - https://docs.pivotal.io/pivotalcf/1-10/monitoring/index.html

Replatforming .NET applications to Cloud Foundry - Migrating .NET apps to Cloud Foundry

A lot of developers do not realize that Cloud Foundry can run a process from any runtime including .NET. Windows applications are managed side-by-side with Linux applications. .NET apps get support for key PCF features like scaling including autoscaling, monitoring, and high availability, logs and metrics, notifications, services including user-provided services and PCF set environment variables. BOSH and OpsManager now supports deployments on Microsoft Azure via pre-built ARM templates.This blog post provides details of the Windows support and provides guidance on migrating .NET apps to Cloud Foundry . This post build extensively on the work done by the Pivotal product engineering and the solutions team particularly Kevin Hoffman, Chris Umbel , Zach Brown, Sam Cooper and Aaron Fortener.

There are two ways to run ASP.NET  apps on Cloud Foundry

1. Windows 2012 R2 Stack

 • Support Introduced in Nov. 2015

 • Supports.NET 3.5-4.5+

 • Requires Diego-Windows, Garden-Windows

 • BOSH-Windows support currently underway
 • App is pre-compiled, no detect. Leverage binary_buildpack  to push app

 • cf push mydotNetApp -s windows2012R2 -b binary_buildpack

 • Runs on Garden-Windows container

 • Win 2k12 provides process isolation primitives similar to those found in the Linux kernel

 • IronFrame abstracts these primitives into an API utilized byGarden-Windows

 • Win 2k12’s low-level API ≈ Linux kernel’s API

 • Therefore Garden-Windows process isolation functionality ≈ Garden-Linux

 • Developer OS is Windows

2. Linux cflinuxfs2 Stack

 • ASP.NET Core CLR only
 • Runs on Diego or DEA

 • Standard CF Ubuntu Stack

 • Community ASP.NET 5 Buildpack

 • cf push mydotNetApp -s cflinuxfs2 -b <asp.net5 bp>

 • Garden-Linux is the backing container

 • Garden-Linux containers are based on LXC (Linux cgroups)

 • Developer OS is Win, Mac OSX and Linux

ASP.NET Core vs ASP.NET 4.6

 • ASP.NET Core

• Web API
• ASP.NET MVC
• No Web Forms (yet)
• No SignalR

• ASP.NET 4.6

• Battle-tested, hardened
• Many years of testing and improvement
• MVC, Web Forms, SignalR, etc.

Migrating Existing Applications

• For Greenfield Applications Try “Core First” approach

• For Replatforming and migrating Existing Apps Probably ASP.NET 4.x

• Dependencies and framework requirements will likely dictate choice
• All versions of the .NET SDK supported by Windows Server 2012 R2 are supported on PCF including 3.5, 4.5, 4.5.1 and 4.6

Here are some of the details on how Garden-Windows secures applications

Non Cloud-Native stuff you will want to change

 • Reading/Writing to the Registry.

•  Super old versions of ASP.NET. Upgrade to .NET core or ASP.NET 4.x

 • Reading/Writing to the local disk. File systems are ephemeral. Replace usage of the file system e.g. disk logging even temp files with a S3 compatible blob store or external file store.

 • Does the app use integrated Windows Authentication? Replace  Integrated Windows Auth. with ADFS/OAuth2 to leverage UAA and Pivotal SSO Tiles

 • In-Process Session State / Sticky Sessions. Replace InProc, StateServer with out-of-process data store e.g. Redis, SQL Server

 • Externalize  environment-specific config in web.config into VCAP environment variables. If value changes between environments, don’t get it from web.config. Don’t use externalization methods that only work in Azure. If app relies on machine.config or applicationHost.config, could have issues in PCF.

 • For MSI-Installed services or drivers, Bin deploy dependencies with app.

 • Nearly every app will need refactoring to use Console logging and tracing. Customers who mess with applicationHost.config can interfere with tracing, logging, etc.

 • 32 bit ASP-Net builds/References/Builds/apps depending on 32-bit libraries will not work. Use of 32-bit dependencies or when the app is itself a 32-bit app this is a red flag.

 • Does the app run as a service or a WCF Self-hosted services as opposed to IIS-hosted ? These services will need to be self-hosted in IIS as part of the replatforming to PCF.

 • Apps requiring assemblies in Global Assembly Cache won't work in CF.

 • Backing Service Drivers requiring native installers / DLLs may not work in CF.

 • On Demand Apps and ones triggered by job controller will need to be refactored to run in CF to use CF one-off task support coming in the CC v3 API.

• MSMQ and tight integration with other MSFT server products via on-server dependencies will need to be refactored to use external backing services. .NET Core is now supported in the RabbitMQ .NET client.

• Routing to non-HTTP WCF endpoints and listeners for third party middleware will not work since only HTTP based inbound traffic is routed to the windows containers.

• Reliance on Microsoft-specific infrastructure? (e.g. MSMQ, BizTalk, SharePoint, etc). These apps do NOT make good candidates to port to PCF.

.NET Application Selection Criteria

References

• Running .Net Apps on Cloud Foundry: Windows vs. Core
• SteelToe OSS Samples https://github.com/SteeltoeOSS/Samples/tree/master/Configuration/src/AspDotNetCore/SimpleCloudFoundry
• Netlfix stack for .NET http://steeltoe.io/
• Deploying your first .NET app on Cloud Foundry http://engineering.pivotal.io/post/dotnet-quick-intro/
• Garden-Windows Deep-dive http://engineering.pivotal.io/post/windows-containerization-deep-dive/

• DiegoMVC Demo https://github.com/ruurdk/DiegoMVC

• ASP.NET Core Demo https://github.com/ritazh/aspnetcoreapp-cf

• ASP.NET 5 Buildpack https://github.com/cloudfoundry-community/asp.net5-buildpack

• Diego-Windows  https://github.com/cloudfoundry/diego-windows-release

• Garden-Windows https://github.com/cloudfoundry/garden-windows

• Steel Toe https://github.com/SteelToeOSS
• Contoso University: https://github.com/pivotalservices/contoso-university

Creating Chaos in Cloud Foundry

One of the key tenets of operational readiness is to be prepared for every emergency. The best way to  institutionalize this discipline is by repeatedly creating chaos in your own production deployment and monitor the system recovery. The list below is a listing a tools from the PCF Solutions team @ pivotal and others to cause chaos at all levels in the stack in Cloud Foundry.

Tools, Presentations & Repos:
https://github.com/xchapter7x/chaospeddler
https://github.com/xchapter7x/cf-app-attack
https://github.com/strepsirrhini-army/chaos-lemur

https://github.com/FidelityInternational/chaos-galago
https://github.com/skibum55/chaos-as-a-service
Monkeys & Lemurs and Locusts Oh My - Anti-Fragile Platforms

Type of test/event/task
1. BOSH
* bosh target (director ip)
* bosh login (director username/password obtained from Ops Man)
* bosh download manifest cf-(hash) ~/cf.yml
* bosh deployment ~/cf.yml
* bosh vms/cck
* bosh ssh
* bosh logs
* bosh debug (gives you the job/task logs)
2. VM Recovery
* Terminate a VM by deleting it in vSphere, watch it come back up
3. App Recovery
* Terminate an app by using cf plugin, watch it come back up.
4. Correlate logs?
* Watch logs for steps above
5. Chaos Monkeys
* Execute Chaos Lemur and watch bosh/cf respond
6. Director
* Shut VM down/delete in vCenter
* When its down, what app still runs?
* Once VM is gone, how do you get it back/rebuild?
7. Network switch
8. Hypervisor
9. Credentials that expire:
* Certs that have expiration date
* System Accounts (internal CF system accounts)
* vCenter API Account that CF uses
10. Log Insight goes down
11. Kill container
12. Kill VM
13. Kill DEA
14. Kill Router
15. Kill Health Manager
16. Kill Binary Repository
* Then scale
17. Over-allocate Hardware (how do we do it?)
18. Execute and backout a change to CF
19. Bulid Pack Upgrade and Roll Back
20. Right Apps have right build pack
21. Licensing server scenario (for example, can't connect)
22. Double single components (for example, 2 BOSH's)
23. Kill internal message bus
24. DNS
25. Clock drift Chaos Testing Procedure:  Kil vms from vsphere; used bosh tasks —no-filter in a loop to watch resurrector bring them up bosh ssh and sudo kill -9 -1 are also fun bosh ssh’d into a dea and killed a container

Application Transformation - The Pivotal Way

Chapter One: Perspective

Monolithic apps aka legacy applications evolve into a mess of of spaghetti code and features that support production workloads that run from airline systems to nuclear reactors to angrybird servers.

With the evolution of the cloud and the death of traditional enterprise vendors there is a huge wave of transformation sweeping across the entire industry neutering all the traditional heavyweight enterprise vendors unhinging apps from their app servers and running them on lighter weight runtimes or even serverless platforms.   

This wave has unleashed a rethinking of application bundling, packaging and deployment constructs at the logical and physical level in terms of domain modeling and immutable deployments, all leading to microservices based architectures that provide the ability to rapidly innovate with people and code.

From a software perspective a monolith is a combination of business capabilities or bounded contexts all enmeshed with a core context. The process of transforming  an app to a microservices based architecture entails separation of each of these bounded contexts into their own contexts.

Chapter Two: Process of breaking apart a monolith

1. Identify the seams of the application
2. Get started along a seam i.e. with a particular business capability. Ideally this should be something that must be isolated and adds business value.
3. Put fences around the existing feature function by writing tests and  exposing an API

API Fencing and Contracts

4. The API and the tests serve as the moat giving you the confidence to rewrite the existing business capability as a microservice.
5. Ensure that both old and new services are talking to the mothership. Validate that the microservice satisfies all the parent dependencies via canary testing. Optionally the Microservice communicates with the parent through an anti-corruption layer. An anti-corruption layer allows for the refactored microservice domain to remain pure. Think of it as a translator that speaks the languages of both the parent and the child.
6. Route traffic to both the monolith and the microservice with Blue/Green deployment.
7. Wrap the older feature code within the monolith with a feature flag disabled by default.
8. Once the microservice is functioning as expected then disable the same feature in the monolith.
9. Delete the Feature Flag  and the code associated with the feature in the monolith.
10. You have now successfully decomposed the business capability from the parent.
11. Scrub and repeat for all bounded contexts.

 Refactoring Legacy code with an Anti-Corruption Layer https://leanpub.com/Practicing-DDD 

Chapter Three: Identify the seams

One of the most difficult aspect of transformation of an app is figuring out where the seams lie.

The best way to do this is to talk to maintainers and users of the application. Users will describe difficulties in interacting with the application giving hints into which portions of the app need to be rewritten. The app maintainer has intimate details about the sections of code that are stable and those that change very frequently.

Static code analysis with code coverage tools will provide insight into code complexity, external dependencies and coupling. Runtime code analysis with logs and sequence diagrams will provide a map of data of event flows through the application.

Exercises like event storming will map out all the epics and user flows through the monolith. Event Storming is a useful way to do rapid "outside-in" domain modeling: starting with the events that occur in the domain rather than a static data model. Run as a facilitated workshop, it focuses on discovering key domain events, placing them along a timeline, identifying their triggers and then exploring their relationships. Event Storming provides a way to discover the big picture, with the goal of collectively understanding the domain in all of its complexity, before diving into solutions.

The onus is not to do a lot of upfront analysis; rather do just enough to get started. It is important to pick one and get started. Let the process of doing fuel the discovery. In many ways this is similar to hill climbing algorithms.

Chapter Four: People and Process Aspects of Transformation

It is critical NOT to ignore the softer side of app transformation.  The 12 tenets of lean app transformation as laid out in An Agile Approach To A Legacy System are
1. Don't reproduce legacy
2. Always ask the user what the problem is
3. Refactor a legacy application by delivering business value
4. Incrementally build trust - prove that you can do the hardest part of the problem
5. Build a small, self-selected team
6. Don't get hungup on process
7. Involve the whole team with larger refactorings so the team can move on as quickly as possible
8. Effective Teams need breakpoints
9. Don't sat no, say later. Treat politics as a user requirement
10. A System that connects to a legacy system must be tested using live feeds
11. Engage users and they not only won't they turn it off, they will fight some of your battles for you
12. Keep giving a good team motivated by giving them new hard problems - don't waste a good team

Risk Profile with the Pivotal Way

To be successful at application transformation, application decomposition, application replatforming and application refactoring it is critical that you get both the process and technology pieces right. One cannot succeed without the other. That is where a company like Pivotal that builds the PCF platform and runs Pivotal Labs an in house eXtreme Programming consultancy for customer success can help. We believe that the feedback cycle should be as short as possible. Automate everything you can with CI/CD. Build new skills through pairing and by doing. Failure is Productive. Experimentation Informs Strategy and Reduces Risk. Watch One > Do One > Teach One.

12 Factor App Transformation

Taking inspiration from the morning paper, today's blog post is a synopsis of the excellent work published In An Agile Approach to a Legacy System where Chris Stevenson and Andy Pols lay down the 12 the core principles to transform a monolith:

 1. Don't reproduce legacy

 2. Always ask the user what the problem is

 3. Refactor a legacy application by delivering business value

 4. Incrementally build trust - prove that you can do the hardest part of the problem

 5. Build a small, self-selected team

 6. Don't get hungup on process

 7. Involve the whole team with larger refactorings so the team can move on as quickly as possible

 8. Effective Teams need breakpoints

 9. Don't sat no, say later. Treat politics as a user requirement

 10. A System that connects to a legacy system must be tested using live feeds

 11. Engage users and they not only won't they turn it off, they will fight some of your battles for you

 12. Keep giving a good team motivated by giving them new hard problems - don't waste a good team

Recovering from failure in Cloud Foundry Diego

Recovery from failures in running Diego processes or tasks involves a combination of the following steps

1. Look at the current state of the Diego by running the veritas tool on the OpsManager or the Diego Cell VM (bosh ssh diego_cell/0). Run ./veritas autodetect, ./veritas dump-store, ./veritas garden-containers and ./veritas distribution to understand the current state of Diego Deployment.
2. Look at the failing processes using BOSH with bosh instances --ps What process is failing ?. Attempt to fix the failing processes with bosh cck or bosh restart Ensure that all the Diego processes like the BBS and BBS Brain and the Cells are running. Ensure that quorum is maintained between the Diego datastores - Etcd, Consul and BBS. 
3. Pay close attention to the memory and disk quotas necessary for cf app pushes to work. Diego is very conservative in its calculations for the remaining memory and disk capacity for containers. Diego never overcommits if it cannot fit the app under existing quota constraints. For the task to be run by diego the min disk per Cell >= 6GB and min. memory per Cell >= 7GB. In PCF 1.7 we’ve introduced as an experimental feature in 1.7, the ability for you to over-provision / relax the diego insistence on hard commits of memory/disk from the underlying cells.
   
4. Look at the PCF Accounting Report. The accounting report let’s you monitor instance usage. This is kind of handy just to see what’s been running, what’s been scaling, how much you’ve used, etc. gain, this is useful to see am I hitting the limits all the time, or am I traveling well under.
5. Identify repeating errors in the log from LogInsight and Splunk. This will give insight into flapping apps and other zombie instances that could be chewing up the containers. 
6. The rep.CapacityRemainingMemory metric shows the cell server with the least free memory. If this metric reaches or approaches 0, its a key indicator that your foundation may need more cell servers.bbs.LRPsRunning shows the total running Application Instances in your foundation. If this is a capacity issue, adding Cells via OpsManager and redeploying may fix the problem with the increased resources for staging and running apps.
7. For classes of failures where Routes to apps cannot be found go ahead and bounce the bounce the diego brain VMs followed by the BBS VMs. 
8. For Quorum issues between etcd and consul internal stores follow advice given bbs-etcd-consul-2-is-a-cloud. Note these quorom issues have been patched in the later service releases of PCF 1.6
9. Remember before opening tickets for Diego auction and runtime failures -  collect metrics and logs from the Diego Brain, BBS and Cell VMs. Log collection can occur in two ways. 1. For small 2-cell deployments the Logs/Status tab of the OpsManager can be used to download logs; 2. however for a real deployment you will most likely pull out the logs from your syslog aggregator service like Splunk or ELK.
10. Debug Cloud Controller Performance: 
• The total number of requests completed: cc.requests.completed. This is a counter that goes up from zero. The actual number isn't so important, but you might want to look at the rate at which it grows (per min / hour) as that could give you some idea of what a "normal" load is for your CCs.
• You can look at the cc.http_status.5XX metric which tells you how many responses were returned in error. This metric is a counter that starts at zero and climbs up with each 5xx response that is returned. Seeing some 5xx requests isn't always a problem indicator, but if the number is climbing rapidly then that would be bad. Sometimes you will see a high number of 503 requests in the logs. Looking at the growth of this number (per min / hour) would be interesting. It would also be interesting to compare it to the rate of growth for the total number of completed requests. I would expect that normally this should grow very slowly compared to the total number of requests.
• There are a couple interesting metrics under the cc.thread_info.event_machine group. I believe that these report about the thread pool used by the ruby process to handle requests. In a small lab test, these three seemed interesting cc.thread_info.event_machine.connection_count, cc.thread_info.event_machine.threadqueue.num_waiting and cc.thread_info.count.  The first seems to be similar to cc.requests.outstanding, an indication of how many requests are hitting the server at any given moment.The second looks like an indication of how many free threads are in the thread pool used to process requests. It works in inverse, with positive numbers indicating remaining capacity. The last is the thread count for the app. In a lab environment, this seems to hover around 21. It would grow as more threads are added.

Screenshot credit goes to the very excellent Mark Fynes. Thanks to Daniel Mikusa and Luan Santos for insight into logging and remediation actions.

Migrating JavaEE Apps To the Cloud

Migrating JavaEE Applications To the Cloud

Java EE began with less than 10 individual specifications, but it has grown over time through subsequent updates and releases to encompass 34. Compared to microservices-based architectures, Java EE and its included specifications were originally designed for a different development and deployment model. Only one monolithic server runtime or cluster hosted many different applications packaged according to standards. Such a model runs opposite to the goal of microservices. The latest versions of Java EE added a ton of developer productivity to the platform alongside a streamlined package. [Modern JavaEE Design Patterns]

There are a lot of technologies from the Java EE specification that barely offer any advantages to microservices-based architectures, such as the Java Connector Architecture or the Batch Processing API. When building microservices architectures on top of Java EE, look at the asynchronous features and use the best available parts.

The document below details which Java EE specifications are a proper fit for implementing cloud native apps. Apps that leverage the JavaEE Web Profile make the best candidates to movet to the cloud. Please see the table below for a detailed treatement of Java EE spec. suitability in the cloud.

Deployment of Java EE Apps To Cloud Foundry

The restrictions imposed by the Cloud Foundry platform allow the platform to scale and provide qualities of service like app lifecycle management, dynamic routing, health management, monitoring, recovery, log aggregation and infrastructure orchestration. Cloud Foundry as a platform optimizes for stateless web apps with light footprint. Some of the recent features ofCloud Foundry like TCP Routing, Deigo container runtime and Docker support have reduced the constraints of the apps running on the cloud.

Cloud Foundry leverages buildpacks to create immutable app artifactions called droplets. A droplet represents a fundamental unit of scaling and immutable deployment in Cloud Foundry. Java apps in CF can be staged and run with the Java Buildpack, TomEE Buildpack, JBOSS Buildpack and Liberty Buildpack.

The capabilities of these buildpacks as they relate to running JavaEE apps are as follows:

Java Buildpack

Provisions a plain vanilla Tomcat servlet contatiner. This buildpack is ideal for spring apps, fat jar apps or apps that come with batteries included. JBP auto-configures data-source beans in the Spring Application context to connect to the appropriate services in the cloud.

WebSphere Liberty Buildpack

Buildpack uses IBM JRE 8 and enables Java EE 7 Web Profile features for WAR and EAR applications. Liberty Buildpack can be easily configured to switch to JavaEE6 or JRE7 using configuration override environment variables. This is the most natural target for moving apps from WebSphere Application Server Network Deployment or Websphere Application Sever Base apps. The following list of Liberty features will be enabled in the default configuration: beanValidation-1.1, cdi-1.2, ejbLite-3.2, el-3.0, jaxrs-2.0, jdbc-4.1, jndi-1.0, jpa-2.1, jsf-2.2, jsonp-1.0, jsp-2.3, managedBeans-1.0, servlet-3.1, websocket-1.1. The Liberty Buildpack accepts .ear. .war. .jar files and full server packages. [Upcoming Liberty buildpack changes]. The Liberty buildpack auto-configures the server based on managed services bound to the application.

TomEE Buildpack

The TomEE buildpack is the smallest delta on top of the Java Buildpack to support the Java EE specification. Apache TomEE is an all-Apache Java EE 6 Web Profile certified stack. Apache TomEE is assembled from a vanilla Apache Tomcat zip file. TomEE starts with Apache Tomcat, adds jars and zips up the rest to provide the Apache TomEE Web Profile i.e. Servlets, JSP, JSF, JTA, JPA, CDI, Bean Validation and EJB Lite .

JBOSS Buildpack

The JBOSS Buildpack provisions full and web profile implementations of Java EE. The buildpack only stages war files and has no support for ear files. JBOSS Buildpack function is currently being enhanced to autogenerate the standalone.xml configuration based on bound services.

Java EE Web Profile

Specification	Versions	Suitability	Cloud Nativity
Servlet	3.0, 3.1	Yes	Non-blocking I/O, upgrade to WebSocket, security. The servlet specification also allows the use of asynchronous request processing. The parts that need to be implemented are thread pools(using the ExecutorService), AsyncContext, the runnable instanceof work, and a Filter to mark the complete processing chain asynchronous.
JSP, EL, JSTL, JSF	2.2	Yes	Although JSF 2.2 is a point release it contains a number of features important to the community.In general there are few issues using HTML 5 with JSF. HTML 5 features such as JavaScript, WebSocket, local storage, canvas and web workers can easily be used with JSF. The only identified issue thus far had been using newer HTML 5 markup with JSF components since JSF components do not recognize these markup elements out of the box. The solution in JSF 2.2 is to allow for freely mixing and matching HTML 5 markup with JSF via pass-through elements and attributes.The older and redundant managed bean model is now being deprecated in favor of the CDI programming model. This is part of the overall platform alignment with CDI. As part of this alignment the very useful view scope previously limited to JSF managed beans is now available to CDI beans.The flow scope is an extremely useful addition to JSF. It allows for beans that automatically live and die within a given boundary in the application (e.g. account management section, catalog section, search section).
JAX-RS	1.1, 2.0	Yes, JAX-RS is the primary building block of the Java EE microservice stack	The primary goal of JAX-RS 2 is improving portability by standardizing common non-standard features in JAX-RS implementations like Jersey, RESTEasy and Axis. One of the most significant changes is adding a client-side REST API. The Fluent API uses the builder pattern and is at the same time very simple but powerful.The addition of message filters and entity interceptors significantly improve the extensibility of JAX-RS. While message filters are conceptually similar to Servlet filters, entity interceptors are similar to CDI interceptors. While it is possible for end users to use message filters and entity interceptors the more likely users are framework and plug-in writers.Asynchronous processing can significantly improve scalability for the most demanding applications. JAX-RS 2 adds simple asynchronous processing capabilities both on the client and server sides.
WebSocket	1.0	Yes, WebSockets are supported by CF	WebSocket is a key part of the HTML 5 family of standards. It allows for TCP like stateful, full-duplex, bi-directional, asynchronous communication over the web. Unlike stateless vanilla HTTP, WebSocket is useful for cases such as online multiplayer game-like applications, online chat-like applications or stock ticker-like applications.The Java API for WebSocket is a high level API similar to JAX-WS and JAX-RS. There is both a server-side and a client-side API for easily developing with WebSockets. Most of the time you will likely be writing Java server-side endpoints while the client side is written in JavaScript.There is both a declarative annotation centric API as well as an interface centric programmatic API. You will most often likely use the annotation-centric API. The programmatic API is useful for dynamically changing WebSocket endpoints at deployment time, perhaps very helpful for framework writers.
JSON-P	1.0	Yes	JSON is quickly becoming the de-facto data serialization protocol on the web, especially with HTML 5.The goal of the Java API for JSON Processing (JSON-P) in Java EE is to standardize JSON for Java, reduce dependence on party frameworks and reduce application complexity.Similar to the Java API for XML Processing (JAXP), JSON-P is a lower level API to handle JSON. It is not a higher level declarative binding API like the Java API for XML Binding (JAXB). Such an API is forthcoming in Java EE 8 and will be named the Java API for JSON Binding (JSON-B).
JPA	2.0, 2.1	Yes, As long as the database and the 2nd level cache is injected as a backing service.	JPA 2.1 standardizes a bunch of non-standard features like schema generation and stored procedures. JPA 2nd level caches should be located outside the JVM and injected as a backing service. Unsynchronized persistence contexts and entity graphs are other optimization introduced.
CDI, Interceptors, Managed Beans, DI	1.0, 1.1	Yes	The CDI specification has become the fundamental building block of the Java EE platform. Java EE7 and Java EE8 is completely being reworked on top of CDI. In addition to providing dependency injection CDI provides eventing, interceptors, decorators and other core application services.
EJB	3.1, 3.2	Yes	Java EE 6 EJBs run perfectly fine on Cloud Foundry as long as the remoting protocol is HTTP. Stateless session beans and singleton EJBs run unchanged on the platform as long as the EJB container. Stateful EJBs should not be passivated locally. Stateful EJB passivation will only work with an external distributed cache.
JTA	1.1, 1.2	NO	2PC Transactional commit does not work across multiple distributed REST services. Prefer BASE(Basically Available, Soft state, Eventually consistent) over ACID(Atomicity, Consistency, Isolation & Durability). Transaction managers typical write transaction logs to local file system and rely on persistent server identity - both of these are not available by design in CF. The workaround here is using standalone transaction managers like Atomikos and Bitronix. Introduce eventual consistency patterns
Concurrency Utilities	1.0	Yes	The concurrency utilities for Java EE provide a framework of high performance threading utilities and thus offer a standard way of accessing low-level asynchronous processing.

Java EE Full Profile

The JavaEE full profile has a numnber of management and security technologies that no longer apply in the cloud. Since the platform takes care of application lifecycle management, deployment, scaling , health management and monitoring of apps. Therefore specifications like J2EE Management, Javabeans managment framework are no longer relevant in the cloud. A small subset of specifications like JAXB, JDBC and JMX still apply in the cloud and will work as is in cloud foundry.

In terms of web technologies in the full profile most specifications work unchanged in the cloud; however specifications like JAXR and JAX-RPC are no longer relevant to modern microservices architectures. SOAP based JAXWS webservices will run unchanged in an app server- buildpack that supports the full profile.

Full profile Java apps in general poor candidates to migrate to the cloud.

Other Technology Constraints in moving to the cloud

In addition to the evaluating the suitability criteria from a Java EE perspective there are other views of suitability as well. It is critical to look at the app from multiple lens to determine app suitability. Some of these technology Barriers To Moving Apps and Services to Cloud Foundry are:

• Language/Runtime Characteristics: CF only supports languages that have a buildpack that run on Linux. Cloud Foundry currently supports Ubuntu Trusty and CentOS 6.5 on vSphere, AWS, OpenStack, and vCloud infrastructures.
• Degree of Statefulness - Runtime state includes caching and Sessions. Coordination of state across peer instances impacts performance. Any application that requires persistent heavy data processing. Apps that require large-scale stateful connections to external services. Use of frameworks that persist client state on the server side like JSF. Apps that keep a large amount of critical runtime state within the JVM i.e. stateful apps are bad candidates to the PaaS. Ideally all persistent state should reside outside the app in a HA data persistence tier.
• File System - Cloud app instances are ephemeral. Local file system storage is short-lived. Instances of the same app do NOT share a local file system.Avoid writing state to the local file system. Does the app rely on a persistent local filesystem or storage ?
• Configuration - Configuration should live external to the deployed app. Config must come from the Environment via environment variables via external configuration server. Apps that have embedded property files or one war/ear file per environment require the refactoring of configuration code before running on the PaaS. We recommend one code base tracked in revision control across multiple deploys. Can you deploy to multiple environments with single codebase.
• Web Frameworks : Does the app leverage Java EE or Spring Frameworks and if so are the libraries bundled within the app or come with the app server. If there is strong dependence on an application server like WebSphere to provide dependencies or if proprietary application server APIs are used then that forces the app to use a particular buildpack or worse refactoring to start embedding the libraries within the app.
• Startup/Shutdown Characteristics: Prefer apps that start cleanly without a lot of upfront initialization, coordination and shutdown without the need for comprehensive cleanup of state.
  Is a startup/shutdown sequence necessary for your app to run effectively. Avoid creating any process instances outside the staged runtime.
• Scalability of the App - Does the app rely on X-axis(horizontal duplication, Scale by cloning), Y-axis (functional decomposition, scale by splitting different things) or Z-axis (data partitioning, scaling by splitting similar things) ?. Design app as one or more stateless processes enabling scale-out via process model.Which other dependent services needs to be scaled when the app is scaled ?
  Dependencies - How are external dependencies wired into the app ? Are dependencies isolated and explicitly declared.http://microservices.io/articles/scalecube.html
• Inbound Protocols - Only a single inbound port is open to an application. Only protocol supported by CF is HTTP/HTTPs/WebSocket. No other protocols like RMI or JMX will work (unless tunneled over HTTP) on the inbound side. HTTPS is terminated at the load balancer. App that relies on transport security at the server will need to be modified. Apps that hold persistent long running socket connections to the server will not work, with apps using WebSocket being the only exception. Any sort of direct peer-to-peer messaging or custom protocol will not work since the warden containers are configured for ingress only over HTTP.
• Logging - Are there multiple log streams ? Is there a strong requirement on local persistence of the logs ? Treat Logs of the app as event streams. Prefer console based logging to file based logging. Configure app server logging to log to the console (stdout/stderr) and thereafter drain to a long-term log analytics solution. Logs written to the local file system in CF are not persisted.
• Rollback - Immutable code with instant rollback capability. Can the app tolerate multiple versions ? Can the app be reverted to a previous version with a single action ? Does deployment of the app require orchestration of multiple steps.
• Security - Does the app rely on network centric or app centric security model ? We recommend relying on on application Layer 7 security rather than network security based on Firewall rules. How are application users authenticated and authorized. Is a Federated Identity and Authorization solution in place ? In CF, outbound egress from the app is controlled by application security groups applied to the warden container. You will need to configure whitelist rules for the services bound and protocols used for outbound communication.
• Application Size - cf push times out for apps bigger than 250MB. Staging of apps that exceed a certain size becomes a big drain on resources for network marshalling/unmarshalling as well as runtime memory footprint. Keeping the droplet smaller results in faster deployment. client_max_body_size can be used to changed the max upload size on the Cloud Controller.
• Performance & Monitoring - Can the app exhaust CPU under load? Are there any concurrency bottlenecks ? Can the app be instrumented for metrics ? Does the app provide a health check/actuator support in production. Does the app leverage app correlation IDs for distributed requests & responses. Does the underlying platform provide basic monitoring(CPU, Disk, Memory) and recovery (Spawning of exited instances) and instant(manual/automated) scaling. Can the logging and admin operations be enabled via runtime switches aka curl requests ?
• Developer Experience - Does app architecture and web frameworks facilitate local development and cloud production. Does the app ruin on runtimes that run equally locally and in the cloud. Does the app use (Spring) profiles to encapsulate conditional app. configuration.
• Cloud Native Architecture - Does the app compensate for the fallacies of distributed computing by leveraging framework libraries like Netflix OSS and/or SpringCloud OSS ? Does the app leverage zero downtime practices of forward and backward schema compatibility for REST microservices and databases. Can one service be deployed independently of other services. Is lockstep deployment of physical war’s needed to manifest a logical app ?
• Data Tier Services/Databases - Any persistence employed by the app has to be synchronized across datacenters and availability zones. The data tier/ Stateful tier of the app has to be managed in lock-step with the stateless tier. Focus has to be put on live content and data migration along with CAP theorem issues. App code has to be forward and backward compatible with schema changes in the data tiers.

Summary

Java EE provides an excellent substrate for a next generation microservices development. As long as you stick to the more recent versions of Java EE (6,7,8) particularly the web profile applications can be implemented and scaled at web scale. It is critical that services follow good design principles of domain driven design, designing for failure, decentralized data management, asynchronous inter-service communication, discoverability and evolutionary design. Existing apps that run on WebSphere Application Sever Network Deployment today are natural candidates to move to the WebSphere Liberty Profile Buildpack. Use the JBOSS and TomEE buildpack for non-WebSphere apps that need a ligter weight more agile runtime in Cloud Foundry. A couple of other options that have not been explored are Dockerizing apps and running apps as fat-jars within Cloud Foundry. For a complete treatement of using Dockers and fat jars please see article and workflow below on migrating WebSphere apps to Cloud Foundry.