NJUG: App Servers are Dead

This is a retooled presentation originally written by Eberhard Wolff (@ewolff). I presented it at the February 2015 Nashville JUG.

Transcript

1. Java App Servers are Dead Greg Turnquist (@gregturn) courtesy of Eberhard Wolff (@ewolff)
2. An Application on a server needs an Application Server
3. Why?? The Price We Pay What now?
4. App Server… • …container for multiple applications • …infrastructure • …deployment • …monitoring
5. • Isolation • ClassLoader • Can lead to non-trivial problems Multiple Applications App Server App 1 App 2 App 3 App 4
6. Isolation • ClassLoader is not enough • CPU? • Memory? • Filesystems? • Applications are not truly isolated • This isolation is what Operating Systems do
7. • Is this what really happens? • Java EE spec talks about “components” • Not Apps Multiple Applications App Server App 1 App 2 App 3 App 4
8. What It Is More Like… App Server App 1 App Server App 1 App Server App 1 App Server App 1 App Server App 1 App Server App 1 Cluster
9. App Server… • …container for multiple applications • …infrastructure • …deployment • …monitoring
10. Infrastructure: Net / Threads • Support, i.e. for HTTP and thread pooling • Connection pooling • Can be done inside the application • Embedded servers (Tomcat, Jetty, Netty, etc.)
11. Infrastructure: Libraries • EJB, CDI, JPA, JSF… • Version tied to App Server version • App depends on Application Server • New libraries can’t be used until new App Server in production
12. Infrastructure: Libraries • Usually not every need covered • …so additional libraries are used • App Server libraries can be replaced by libraries • Makes application more portable • If you need additional libraries anyway… • …why not just package all of them?
13. Infrastructure: Application independent? • Each application has its own infrastructure • E.g. database connection • + specific configuration
14. Dependencies: App Server / Application App Server Application Libraries Infrastructure Specific configuration Cyclic dependency i.e. one component 1 App Server per Application
15. You Don’t Agree? • Can you deploy your application on a different server? • On a different version of the same server? • Without modifications to the server? • Do you deploy other applications on the App Server? • Could you? • is the application server or an installation script in your version control?
16. Application Servers are just another part of the Application
17. App Server… • …container for multiple applications • …infrastructure • …deployment • …monitoring
18. Deployment • Deployment Format: WAR, EAR, JAR… • Can’t define dependencies outside application • i.e. App Server version, database etc. • Operations usually work with deb, RPM, docker… • Completely different tool chain • Also: Usually UNIX services to start/stop
19. App Server… • …container for multiple applications • …infrastructure • …deployment • …monitoring
20. Monitoring • Provided by JMX • Can be integrated with SNMP, etc. • Works outside App Servers, too
21. Monitoring • New tools arise • Logs + Logstash / Kibana or Splunk • New Relic • Hadoop log file collection / analysis • REST-based monitoring resources • Scripts for monitoring
22. App Servers are needed for monitoring and deployment
23. App Servers come with a proprietary Ops Tool Set
24. App Server… • …container for multiple applications • …infrastructure • …deployment • …monitoring 1 App per Server (or cluster) App server part of application Deployment & monitoring OK but not standard tools
25. The Price We Pay
26. • Code • Package a WAR • Instal it • Unpack the WAR • Test • Solutions: JRebel, Spring Loaded • But: Why is it done at all? Slower Turnaround Why??
27. App Server: Complex Deployment • Deployment: not just an application • But also an Application Server • App Server configuration more complex than Application configuration • Look at automation scripts with Puppet / Chef, etc.
28. Cyclic Dependency Application - App Server • Application and App Server must fit each other • Configuration must be compatible • For each developer and each testing stage • Old configuration e.g. for bug fixes • Hard to get right
29. More Apps & Deployments • Continuous Delivery: Applications deployed more frequently • …in many different stages • Micro Service: Many more apps • SImple deployment even more important • App Servers become bigger headache
30. Different Ops Mindset • App Server administrator? • Deployment, monitoring, etc. have been solved already! • Package manager • Ops Monitoring • Why not stick to general solutions?
31. The Price We Pay App Server Slow Turn Around Standard OPs Tools Continuous Delivery Micro Services App Server specific OPs tools Deployment complex One infrastructure doesn’t fit all One App Server per Micro Service? Smaller deployment units
32. RIP Application Server!
33. What now???
34. The Re-Rise of the Applications • Create JAR files • …that contain a main class • Custom infrastructure • e.g. HTTP server • Or Batch • …
35. Monitoring & Deployment • Rely on standard Ops deployment and monitoring tools • REST-based monitoring URLs • Evaluate log files
36. Application: Benefit • Easier to Deploy: Just a JAR • + command line • + config file • Debug & run in IDE • Acceptance tests, etc. run much easier • Ensured: Infrastructure compatible with application & src controlled
37. Spring Boot Actuator & CRaSH Demo
38. Technologies • Spring Boot • Dropwizard by Yammer • Vert.x • Play Framework
39. Thank you! gturnquist@pivotal.io @gregturn Send thanks to @ewolff