Java cloud solutions (e.g. PaaS) may not support a full stack, and may be overpriced. Discuss.

[Ashley Lester]

(Not sure if this belongs in this forum. Was thinking of posting it in 'meaningless drivel' or 'java ee'. Please move if I'm in the wrong place.

Java PaaS cloud-based solutions, like Amazon Web Services, Heroku, and so on, may not support the full stack of Java enterprise architecture, such as EJB's. Most Paas providers package a Tomcat servlet container which isn't a full application server. Those services supporting the full stack, like Oracle Cloud, charge hundreds of dollars per instance per month, which is ridiculous for those who are learning and want a person website hosted in the cloud, based on Java, supporting EJB's, for instance.

Question: Does the disparity between Java and non-Java application servers in the cloud persuade people to use lighter frameworks like Ruby on Rails, or Django, and is this a problem?

From a personal point of view, I'm certainly finding it difficult to justify developing a web application in Java if and when deployment happens, I might be using technologies which aren't supported, or technologies I would have to pay through the nose for.

[Luan Cestari]

OpenShift does support the Java EE standards (you can deploy into a JBoss/WildFly/TomEE/EAP/etc) (and it is supporting (or it is almost supported,not sure) other interesting things like docker)

About the question, I don't think so. I think this is more a generation thing (younger people will have access to technology and want sth very easy to use, and ruby and python is much more intuitive for starters) (which I would summarize that Java get very known and could survive through the time). A second thing is the engineers that built the cloud platform. They had to choose what to support and if the put too much framework and technology that could lead to issues that those external libraries have which would make people lose the trust with the cloud provider which is bad. So they thought to build from the botton to avoid to ask requirements to any external project (making easy to test and maintain) .

[Ulf Dittmer]

This is an odd question, IMO. Developing an application without regard to the target platform where it should run, when you already know that the target platform might restrict what technologies you can use, doesn't strike me as a sensible approach. If you don't want to make assumptions as to the target platform during development (an odd assumption), then you should target virtual or physical hosts, where you can run pretty much anything you want. If you want to target an IaaS or PaaS platform, then that platform will impose restrictions on what you can do. That's true for any language you choose to develop in.

I'm not at all sure what "the disparity between Java and non-Java application servers in the cloud" is, nor do I find it unreasonable that the deployment platform influences the development technologies, especially when there is an extremely wide range of deployment technologies to chose from. Lastly, "having to pay through the nose" is completely context-sensitive as to your circumstances, so we can't comment on that.

[Ashley Lester]

Luan Cestari wrote:OpenShift does support the Java EE standards (you can deploy into a JBoss/WildFly/TomEE/EAP/etc) (and it is supporting (or it is almost supported,not sure) other interesting things like docker)

About the question, I don't think so. I think this is more a generation thing (younger people will have access to technology and want sth very easy to use, and ruby and python is much more intuitive for starters) (which I would summarize that Java get very known and could survive through the time). A second thing is the engineers that built the cloud platform. They had to choose what to support and if the put too much framework and technology that could lead to issues that those external libraries have which would make people lose the trust with the cloud provider which is bad. So they thought to build from the botton to avoid to ask requirements to any external project (making easy to test and maintain) .

Thanks for pointing out OpenShift to me. I've had a look around it and it looks pretty nice, and cheap. I also agree with your point that there has to be a cut-off in what the cloud is going to support, kind of a cost-reward evaluation. I suppose that if you're developing on the cloud, you might not want an industrial component model like EJB for a small website.

[Ashley Lester]

Ulf Dittmer wrote:This is an odd question, IMO. Developing an application without regard to the target platform where it should run, when you already know that the target platform might restrict what technologies you can use, doesn't strike me as a sensible approach. If you don't want to make assumptions as to the target platform during development (an odd assumption), then you should target virtual or physical hosts, where you can run pretty much anything you want. If you want to target an IaaS or PaaS platform, then that platform will impose restrictions on what you can do. That's true for any language you choose to develop in.

I'm not at all sure what "the disparity between Java and non-Java application servers in the cloud" is, nor do I find it unreasonable that the deployment platform influences the development technologies, especially when there is an extremely wide range of deployment technologies to chose from. Lastly, "having to pay through the nose" is completely context-sensitive as to your circumstances, so we can't comment on that.

I agree, development should consider beforehand what platform is going to be used. I don't work in software development (yet). But, iterative development and requirement creep might necessitate a solution which might be outside the offerings of the platform which was considered at the start of the development. I don't know how likely that is.

The disparity I refer to is two disparities, really - that of price, it appeared to me after searching the major cloud providers that java is generally more expensive, and also of features, as in, you might get a servlet container with Java, but an application server with another framework. But, I admit that this has to be compared with the large amount of stuff that you can integrate with Java. You might consider it a more flexible framework than some others.

It may be that enterprise Java, because it contains large, rich, industrial-strength frameworks, and additionally because it is so large, gives it more suitability to the kind of projects which are going to be more expensive.

I may not have phrased the question very well. And, the question is from someone who is not in the industry, so there is a probability that the question doesn't make sense from someone inside the industry. The main point of my question centres around this: consider if you are a learning developer, without much money, and you wanted to deploy a small website in Java, because that is the language you feel comfortable with & learnt with, and you want it to be hosted on a platform offering a server which complies with the EE specifications... well, I certainly felt some discouragement to find that the options I was looking at were making me lean towards a different framework, due to the points above about the price-feature comparison and lack of cheap full EE support.

[Jeanne Boyarsky]

Ashley,
If you are just learning/practicing you don't need to deploy anywhere. You can just test on your machine. A lot less people are using EJBs than in the past anyway. If you haven't taken a look at Spring, consider that. You'll learn about the same amount than if you used EJBs. And Spring runs on Tomcat.

Java and .NET are certainly more expensive to host when you need a full blown stack than Ruby and PHP. I think Ruby is more similar to what runs in a servlet container though. Which is plenty! See my reference to Spring above.

[Ashley Lester]

Jeanne Boyarsky wrote:Ashley,
If you are just learning/practicing you don't need to deploy anywhere. You can just test on your machine. A lot less people are using EJBs than in the past anyway. If you haven't taken a look at Spring, consider that. You'll learn about the same amount than if you used EJBs. And Spring runs on Tomcat.

Java and .NET are certainly more expensive to host when you need a full blown stack than Ruby and PHP. I think Ruby is more similar to what runs in a servlet container though. Which is plenty! See my reference to Spring above.

Spring scared me. I did consider Spring Roo. There are too many frameworks for someone to pick.

Spring scared me because of the xml and the DI. I know I used DI in my Java EE course but that felt like it was more 'hidden' because I was just injecting dependencies into something... I forget what... I think it was something to do with an @remote annotation. It's been a while.

Yep, I am developing on my machine. But it feels nicer to have something more than 1 person can see.

Edit: I'm not against Spring or anything. I've watched a few of the tutorials from koushik on YT. It's taking some time for me to get my head around it. It seems even more huge and wishy-washy and 'do what you want' than Java EE does.

[Jayesh A Lalwani]

Nowadays, most new applications that built on open source technologies are being built on the Spring stack. You don't see support for the full stack among PaaS providers simply because there isn't too much demand for it.

If I put together, Spring Data + Jersey, I can generate a trivial REST interface on the database in a matter of minutes. I don;t need a full application server. I can easily put this on an AmazonEC2 instances fronted by AMazon ELB and backed by Amazon RDS, and I got my web app that is mostly CRUD running. It's rather trivial nowadays to get a scalable and lightweight REST service up and running without the full Java stack. That "problem" is solved without the Java application server

THe problems that the Java's official ecosystem doesn;t provide solutions for is
a) front-end
You don;t get kick ass UI out of the box using Java technologies. You need to dip into technologies outside of the Java's official stack.. or go for solution providers that sell you their own stack
b) back end processing
The only real solution that the Java's official stack has for big data processing is the Message Queue. ANd really.. that doesn;t cut it. Like rest of EJBs, Message Beans are an overblown concept. It doesn't have scaling too. Technologies like Amazon's EMR (Hadoop), Storm, Spark are a really good fit
c) Reporting
You can build a kick ass reporting system using Java. But you don;t get one out of the box
d) NoSQL
Again you can build a NoSQL database in Java but there's nothing out of the box

So, really there are 2 Java worlds out there
One which throws in a huge mix of Open source technologies into the project. None of these people have any need for a full fledged Application server

ANother which sticks to a supported stack (like Oracle's stack). These people are more likely to go with Oracle's cloud.

[Ashley Lester]

Jayesh A Lalwani wrote:Nowadays, most new applications that built on open source technologies are being built on the Spring stack. You don't see support for the full stack among PaaS providers simply because there isn't too much demand for it.

...

So, really there are 2 Java worlds out there
One which throws in a huge mix of Open source technologies into the project. None of these people have any need for a full fledged Application server

ANother which sticks to a supported stack (like Oracle's stack). These people are more likely to go with Oracle's cloud.

That's a very insightful answer. So, reduced demand, open-source developers, lighter-weight frameworks including out-of-the-box juiciness, and an emphasis on stateless RESTful architecture have meant that if you want an Oracle stack, go for it, but it's not where the cool cats are going.

That helps me a lot in figuring out why Java was on the cloud providers, but not in the way I was expecting.

I'm working on a project (part-way through database modelling) which is an Android app which sends info to a server, through which users can log on and do stuff. Its purpose is for surveyors in housing, for mobile working, and so on.

I was going to have a Java EE server for the project. But I think I have the time to look at something else, like Spring, Spring MVC, or Rails, or Roo, or Grails or Play or.......

[Jayesh A Lalwani]

Yes. My personal biases are in play here. If you are completely greenfield, and want to stay in java world, go with spring. It's not easy to learn, but once you learn it, you will wonder how you can live without it.

[Bear Bibeault]

Jayesh A Lalwani wrote:Nowadays, most new applications that built on open source technologies are being built on the Spring stack.

I'll disagree. What I see happening with most "new" apps is creating a simple backend that serves up a RESTful API* and doing everything else on the client with JavaScript MVC frameworks. The days of creating presentation on the server are dying fast.





* Sure Spring could be used here -- but it's kinda overkill unless your back-end business logic is so complex that it needs a framework like Spring.

[Ulf Dittmer]

Bear Bibeault wrote:The days of creating presentation on the server are dying fast.

Stated in this generality, I disagree with this statement. So I think the "What I see happening..." part before it is important. While the shift is happening, and web sites these days should be built to include a REST API, server-side presentation layers are not dying, and certainly not fast. I think it's too early to say whether they will be dying at all, or whether both forms will coexist for a long time.

[Winston Gutkowski]

Ashley Lester wrote:I'm working on a project (part-way through database modelling) which is an Android app which sends info to a server, through which users can log on and do stuff. Its purpose is for surveyors in housing, for mobile working, and so on.

I'm certainly no JEE or Spring expert, but I have designed and worked on enterprise solutions before, and I wonder if you're not overthinking this. Part of the art of large-scale programming (and, for that matter, OO) is to defer decisions that don't need to be made. You, on the other hand, seem to be trying to plan for scenarios that I'd say simply aren't relevant...yet. Sure, you know that your system is likely to need to use "the cloud", but while you're still designing your database, it seems a bit premature to be deciding whether you're going to use Swing or JEE (or whatever) for your "glue".

EJBs always seemed to me to be, in most cases, a sledgehammer to crack a walnut, but at the end of the day they're simply a layer of indirection; and providing you design your db (and presumably the "model" to go with it) well, I don't see any particular reason why you shouldn't be able to plug it into any cloud framework you choose when the time comes. Furthermore, you can probably test it as a standalone app initially without any of that extra "plumbing", and I suspect the same is also true of the 'C' and 'V' portions of your system (not quite so sure about the latter though).

Just FYI: When you do get to the stage of testing the system as a whole, one tool that I've found invaluable is VirtualBox, which allows you to boot not only separate machines, but different operating systems from a single machine (or laptop). Furthermore, you can treat them as though they're on entirely different networks by using 1918 addresses. And best of all: it's free.

HIH

Winston

[Jayesh A Lalwani]

Bear Bibeault wrote:

Jayesh A Lalwani wrote:Nowadays, most new applications that built on open source technologies are being built on the Spring stack.

I'll disagree. What I see happening with most "new" apps is creating a simple backend that serves up a RESTful API* and doing everything else on the client with JavaScript MVC frameworks. The days of creating presentation on the server are dying fast.





* Sure Spring could be used here -- but it's kinda overkill unless your back-end business logic is so complex that it needs a framework like Spring.

Yes, I think we are saying the same thing . I never said that Spring should be the "presentation" layer. If you read my previous post, I explicitly say that the front end has to be outside of the Java stack. It's pretty trivial to setup a REST API if you use Spring and then use something else to drive the presentation on the browser/device.

I don;t see Spring as overkill, if you used it the right way. Spring is providing you a lot of functionality, and you are really connecting the dots together. Let's say If I want to build a REST API on top of one domain object. Using the Spring stack, I am writing 5 classes:- an entity class that represents the domain model (lines of code = approx 10 lines per property) , a Spring data interface (3 lines of code), a REST class (probably 50 lines of code), a configuration class that sets everything up (probably another 40 lines of code), and finally write the Unit test. It's more or less 100-200 lines of code. If I have done this 3 times already, and I have done my design, I can bang a new REST api out in 15-30 minutes. This allows me to focus on the design of the domain model, and the REST interfaces, without worrying about the nitty gritty of the implementation. My "implementation phase" is basically just taking these blocks that Spring has provided, and connecting them together