Here is a quick field report from JavaOne!
We’ve talked to dozens of people, and the theme we keep hearing is simplicity, simplicity, simplicity.
Many amazingly bright application architects have stopped by to understand and learn more about the vFabric application architecture, and these folks hail from a number of industries – giant telecom manufacturers, government ministries of defense, and multi-industry service companies to name a few.
These conversations with architects have tended to fall into one of the falling categories:
2. Simpler ways to reduce Java memory. Another common scenario is that developers frequently request insanely large VMs to run Java applications. Here we are finding that architects are skeptical of such requests and need to know whether so much memory is required, but don’t have the tools to do so. They’re curious about Elastic Memory for Java (EM4J) and how EM4J’s sizing tools help reduce Java memory on vSphere. The EM4J screenshot below shows an example virtual machine with a great deal of wasted memory. First, not all the VM memory (vRAM) is used, even when maximum Java heap and native OS and JVM memory is taken into account. Second, only a fraction of the allocated Java heap is used. EM4J shows that two simple ways to reduce Java memory here would be to reduce the vRAM allocation and the max heap size (-Xmx).1. Simpler application servers: One of the most common scenarios we are hearing is where people are running Spring workloads on WebLogic or WebSphere. They’re asking themselves why they’re spending so much in licensing costs to run these workloads, and torturing themselves with high levels of complexity. They’re looking for a more cost-effective and simple way to run Spring Java and are intrigued by how tc Server can help. One company told us they are running over 1000 unique custom apps, and even simplifying a percentage of those applications would have enormous value.
3. Simpler ways to manage Tomcat: Teams who run Apache Tomcat want a more enterprise-ready way to manage and monitor Tomcat. Rather than a long trial-and-error process of checking out various tools, they want an application server that preserves the best features of Tomcat, but works out of the box and lets them be instantly productive. As a result, they’re interested in tc Server, with Spring Insight for application code monitoring, both in development and production, vFabric Admin Server for management, and more.
4. Simpler ways to provision: Architects are very interested in automatic provisioning of application infrastructure, but there is a challenge: vSphere admins want and need a certain amount of control over VMs – they cannot allow an application operations team to just spin up VMs whenever they chose and risk using up all the capacity on their vSphere hosts. At the same time, application teams need the ability to add VMs on demand to scale, add failover, and so on. Thankfully, Application Director provides a way out of this dilemma: it simplifies app provisioning for application teams, yet allows vSphere admins to constrain what those team can do via role-based privileges.
5. Simpler web services: At JavaOne shows a decade ago, we’d often talk about what could be now called traditional SOA, which focused on XML, SOAP, WSDL, UDDI, etc. Today, the architects we talk to are opting for simple SOA: requests created in JSON, not XML, and sent to RESTful endpoints (not WSDL) backed by Spring MVC or Spring Data REST. And the discoverability promised by UDDI is now increasingly being implemented with HATEAOS. In fact, the one piece of traditional SOA that remains is HTTP – itself a relatively simple protocol.
If you haven’t, please stop by our sessions or the booth (#5302) at JavaOne.