Ready, Steady, Vir…Go!

onYourMarksSeveral months ago I took over the project lead for Virgo. The project code base and vision had been established by SpringSource dm Server[1] and later on by VMware[2] and SAP[3]. After an assessment of what Virgo can do today and where we see a future for Virgo in the application server market, we want to share our vision for the future of Virgo with you – our collaborators, adopters and users.

Where we are today

As of today, you are able to scale up and scale out easily with Virgo. You can run OSGi applications with Virgo on a Raspberry Pi[4] or a large Amazon node. With lightweight container technology like Docker, you can easily automate the installation of Virgo[5] and support continuous deployment[6].
This enables you to scale out with a modern cloud-independent technology.

Still it could be easier to develop, deploy and monitor Virgo-based applications.

Our vision

Our vision is that Virgo becomes the leanest and easiest-to-use server for modular applications. We will achieve this by focusing on single application installations per server. Server and application become an atomic deployment unit. Virgo will continue to expose OSGi to the application and make it easy to blend the server into a standalone application. You can benefit from the powerful service-oriented programming model of OSGi to leverage loosely coupled modular application with reusable components. You can easily ship your application and the extensible server in a single step without having to create a war artifact. During development it will be very easy to test-drive and debug the single deliverable with a live command shell, e.g. in the same lightweight container that is used in production.

For the past two decades, application servers have been designed to handle deployment of multiple applications, update of applications and shared-anything deployment scenarios. Virgo has been no exception, it implements shielding of entire OSGi environments in one application server instance. But the world is moving on to new deployment standards. With virtualization and lightweight containers it has become feasible to make deployments immutable. If you want to change anything, you make a new deployment next to the existing one. Application deployments get managed from the outside, not within an application server any more.

Deploying applications in an immutable style has become the de facto standard of the internet industry. Application servers today have not been designed for this purpose. But for Virgo and the existing Virgo Nano deliverable, it is a relatively small step getting there.

To implement our vision, we will provide a streamlined Virgo distribution build on top of Virgo Nano. The main focus is running HTTP based modular apps on environments ranging from small devices to cloud farms.

What does that mean?

In the new development stream we will introduce Virgo Nano Jetty and Virgo Nano Tomcat as the main deliverables. Based on this HTTP ready package, we want to make it easy to add more modules to the mix. Either during the packaging process (e.g. a Maven Mojo) of your application, or via scriptable Virgo and the possibility to export a self contained, easily customizable deployment unit:

$ bin/virgobuild.sh add my-application.plan
$ bin/virgobuild.sh add customer-A-specific-addons.plan

$ bin/virgobuild.sh configure user admin/s3cr3t
$ bin/virgobuild.sh configure httpPort 80

$ bin/virgobuild.sh package my-application-with-customer-A-specific-addons.zip

We intend to provide tooling for the new flavour and add Docker support to the Virgo Tooling to make it easy to run and test your application in virtualized environments.

We’d like to hear your feedback so please comment on these ideas and let’s carve out the details together.

[1] https://spring.io/blog/2008/09/11/springsource-dm-server-1-0-rc2-released
[2] http://underlap.blogspot.de/2012/10/virgo-in-vsphere.html
[3] http://www.infoq.com/news/2012/12/sap-netweaver-cloud
[4] http://eclipsesource.com/blogs/2014/02/18/a-lightweight-java-application-server-on-raspberry-pi/
[5] http://eclipsesource.com/blogs/2013/07/03/automated-installation-of-virgo-with-docker/
[6] http://eclipsesource.com/blogs/2013/10/25/continuous-deployment-with-docker-and-virgo/

9 Comments
  • Jörn
    Posted at 6:13 pm, May 15, 2014

    I like the decisions you’re taking and the USP you are proposing (immutability, docker-friendly, appliances, ready for the new deployment world). Just one question: I see there is no blueprint in the nano packages. Any plans for this?

    Kind regards,
    Jörn

  • Yannick
    Posted at 7:06 pm, May 15, 2014

    I totally love the idea of 1 app per Virgo (the framework IS the application) and your focus on continuous delivery. Let make that a reality !

    Best regards,
    Yannick.

  • Miles Parker
    Posted at 2:07 am, May 16, 2014

    Great! This step will by itself devour so many deployment and configuration hassles and incidentally allow some time tooling improvements. Click here, get app. Light-weight all the way!

  • Daniel Marthaler
    Posted at 9:25 am, May 16, 2014

    Sounds great, as we already handle our Virgo deployments in this manner the proposed direction is a perfect match to our requirements.
    Indeed, Gemini Blueprint support is a must from my point of view.

  • Mathilde Ffrench
    Posted at 11:43 pm, May 16, 2014

    That’s sounds very great for me. Particularly I guess this will be the occasion to check again some really usefull virgo artifact deployment shell commands which seems bugged to me like plan start/stop in 3.6.2 ?

    As I’m currenty looking to the Virgo code and trying to build my intellij env. for Virgo I also would like to know if you have any building tools migration in the pipe as it seems to me that ant-ivy could be replaced by much better tools ?

    Thank you for your great job and long live to virgo 😉

  • Diego Visentin
    Posted at 12:00 pm, May 17, 2014

    Many years ago I tried with success this model using Project Zero (a tentative of IBM to explore new directions on application server and development side) . Other than one-app-one-runtime, PZ had a smart approach about memory leaks: automatically restarts every x interactions or time. Seems silly but I found very effective and pragmatic 😉

  • Mathilde Ffrench
    Posted at 11:32 am, June 26, 2014

    Hello,

    as your analyse is not so far with the “new” micro service trend (http://martinfowler.com/articles/microservices.html), I’d like to know if you may be interested by provifing a service registry distribution. I’m currently checking – and loving – akka framework and I think it could be an excellent stack to distribute my app and so the OSGI service registry…

    Tell me what your think…

    Cheers,

    Mathilde