Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am planning to program a software (in java), which will be (hopefully) used very much. In the beginning I may run it on my own server, but if it becomes popular my server will most likly crash.
So my plan is to program it for a cloud service like Amazon EC2, Google App Engine, Lunacloud or others.
The application will not have a gui for now. It will concentrate on SOAP or JMS (or something like that) and should store a lot of data in a relational database (PostgreSQL would be nice).
Since I am new to the cloud services, I tried a little bit with GAE. The main use is easy, but as soon as I use JPA and ManyToMany-Relations GAE is shit. Also making a SOAP or JMS Server in GAE is not simple.
Since I lost my weekend with trying GAE, I thought it would be a good idea to ask the community.
Which cloud service will fit best for my requirements? What are the benefits and differences between these services? What else can you recommend?
This is question is too wide open to provide a good answer, but here is some tips that should help.
There is a difference between platform as a service (GAE, Jelastic, Heroku) and Infrastructure as a Service (EC2).
In the platform as a service category, you have more of an automated infrastructure, and often very little visibility of the underlying components. This can make things easier from a developer perspective, but it has its downsides. You are often locked into how a provider works and it may be difficult to switch. You may also have limitations as to what you can do with your application.
In the Infrastructure as a Service category, you get access to virtual machines that you can configure and automate yourself. You have more flexibility on this type of platform, but you are generally expected to handle more of the work yourself. EC2 does have its own version of platform as a service with elastic beanstalk.
i would recoomend also heroku because it does not have a traffic limit and you can run a basic instance for free. if you dont need nosql dbs and extra software it will be very cheap and the unlimited traffic is good for your webservices. Gae has is own filestructure so i can understand your problems with your db structure very good. heroku and ec2 does not restrict your plans but ec2 is generally expensive if you dont plan to scale up and down often. heroku gets also very expensive when you want to add extra software and scale up. i dont know if youre able to scale up as good as with ec2 if you want to use jelastic.
another but complex approach would be renting some normal root servers with unlimited traffic where one instance act as load balancer but you would have to do the configuration by yourseld
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am making an API with Spring boot which will maybe have requests peaks.
So let's get into the worst scenario. Imagine that suddenly I have 2 million API requests.
What can I do to be able to handle this?
I read something about queues and workers but I don't know if that's the best way.
Is there some way to do it with something with AWS?
This is always a tricky question to answer. Firstly does your app really need to scale to 2 million API requests at peak? I ask because it is easy to over-engineer a solution 'to deal with future scale' which ends up a bit buggy and not even dealing with current scale very well as a result.
But assuming you really will have massive request peaks, the current microservice approach (or buzzword?) is quite a popular way of dealing with these periods of high demand. Basically you split your application up into smaller, self contained services ('microservices') which can be more-easily scaled as required.
Individual microservices can then be scaled up and down to match the load, using something like Kubernetes or Amazon ECS.
In terms of where Spring ties into this, Spring has a handy set of technologies called Spring Cloud - you'll notice Spring Cloud AWS there, too (although Spring Cloud in general can also work fine on bare metal servers, Docker, Kubernetes etc etc). A year ago I put together a simple Spring cloud/microservices demo on Github which shows how different Spring-powered microservices can fit together, which you may find useful.
The other nice thing with microservices is that you can swap out the language that a particular service is written in fairly easily, especially if the microservices 'speak' to each-other in a general format (such as JSON via REST requests). So if you had 10 different microservices, all powered by Spring Boot, but you find that a couple of them are better written in another language, you can just rewrite them: as long as they send and receive data in the same way, then the other parts of your system don't need to care.
Okay, that's a lot of buzzwords and new concepts. Feel free to ask questions if I can clarify anything, but microservices + kubernetes/AWS is a popular solution.
Other approaches which will probably work equally well, however, are:
Serverless - this is where you use a bunch of cloud-provider's tools and solutions to power your webapp, including things like lambdas, instead of hosting your application on a traditional server/VM. This medium tutorial gives a simple introduction to serverless.
Monoliths - this is a traditional web application which is a single, large, sprawling codebase, but this doesn't mean you can only have one instance of it running (i.e. you can still scale it). This very site is a successfully scalable monolith.
Your question is very broad, as there are lots of different solutions:
1) Use a load balancer and have multiple instances of your application
2) Use a containerization tool like docker and kubernetes to increase the amount of instances depending on current load. You can essentially scale on demand
3) We don't know what your app actually does: is it read heavy, is it write heavy? Will users be downloading content? The answers to this question can change whether or not a specific solution is feasible
4) You can maybe use a messenger queue like RabbitMQ to assist with distributing load across different services. You can have multiple services reading from this queue and performing actions at the same time...but again, this depends on what your app will actually be doing.
Check out AWS EC2 and Elastic Beanstalk. You can also get a simple load balancer up and running with nginx. Good luck
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
My company has a poorly designed system that runs several services in WebSphere. The services currently communicate directly with each other causing poor performance. To address this, they have added several areas of multithreaded code throughout the services that make up the system. I realize that this is not the best solution.
Now, the company has decided it's time to move to a more modern set of tools, and we will be migrating all of these services to run in Docker containers managed by Open Shift / Kubernetes. (I hope I'm saying that right)
My worry is that all of this multithreaded code is buggy and difficult to maintain. I'd rather use a Messaging type of design that eliminates a lot of our service to service communications.
Can someone with some experience in these areas give me some good talking points as to why it's a bad idea to implement your own multithreaded code in the environment like the one we are moving to?
I cannot think of any inherent downside of running a multithreaded application on a single JVM instance (which is what a Docker container will translate) regardless of the environment. A lot of Frameworks, like Spring are already multithreaded.
I must say that your problem statement is a bit too broad to identify what you need help with, but, herewith nonetheless: I get the sense that the concurrency implementation in the application itself is the main concern here. In that case, I would say first look at the dangerous multithreading violations like race conditions, thread starvation, deadlocks, objects that are not Thread-Safe objects, etc. In my experience, these are some of the underlying issues with multithreaded applications. Once these are fixed, there should not be any reason to worry about moving to a different runtime environment like a Docker container, etc
Personally I think you should migrate your application to container format firstly as it is. It's more difficult than our thought in real work.
Yes, it's regardless of multithreading.
First step (most important) : migration of application to container as it is.
Then you start to refactor or to split info small services, this task should be proceed as other branch while operating the existing system which is migrated to container ways.
Rather more important thing is migration of your application or service to container manner. You can get the benefit of automation as of that time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I recently started working for a company, which has outsourced all their IT business, due to several reasons. After a few years, they've started to realize that they are constantly overcharged by some of their external partners, leading to the point where they finally decided to bring in some IT expertise to evaluate possibilities to consolidate their IT costs.
This is where I came in. After now working for 3 months in this company, my boss has suddenly offered me the possibility to re-implement some of the software, which they are currently using as a service provided by an external partner, which would take over starting 2018.
After taking a closer look at what this current software does & how it is set up, it is really incredible what this external partner is charging them for the service, so I'm really tempted to consider the offer for re-implementation. I already gathered some experience with Spring, Spring-MVC and partly Spring-Webflow, setting up a small web-application using a relational database through hibernate (although I wouldn't mind using any other Object-Relational-Mapping as well).
The question that arises now to me is, if I completely overrate the possibilities which Spring is giving me. Upfront now some of the requirements and small description of what the software needs to be capable of:
Web Application based on a relational database server
10.000 users maximum, the daily access to the system is around 100-200 users only(!)
Several roles (admin, manager, customers, end-users) with different views & workflows
all in all several different workflows for each role
the workflows are all based on data only, no heavy calculation or other complicated stuff, really small straightforward workflows of a typical small web application
several smaller interfaces to export/import data, typically provided or delivered via XML/Excel/CSV files
standard security/logging features
As far as I can tell, all this requirements could be easily fulfilled implementing this project as a Spring-MVC/WebFlow application, using the aspect-oriented security/logging approach of current Spring versions, with any modern RDBMS working in the background.
Right now, my company is paying 5-digits numbers per month for the use and service of this system (which by the way is a standard-product from that rather small external IT company, only issue is, that there are barely no other software products in this branch by other companies), while still having to pay a lot of money on top for every small change (minor changes to the workflows, changing text on existing pages).
So this is really a very tempting offer, since the software requirements are rather standard from my point of view, and in my opinion, Spring would provide a perfect base for such an application.
My main question is, am I overlooking something in the here stated requirements, which are not feasible via Spring.
Thanks ahead for any input regarding this topic, while I continue my evaluation of it by myself.
Taking a look at your requirements, I don't see anything in there that you couldn't reasonably easily implement using the Spring stack.
A few things that you haven't mentioned:
Start by using Spring Boot. It will vastly simplify the configuration you need to get up and running with Spring.
It would probably be best to use Spring Data JPA in order to handle most of your persistence needs (since as you mention you will be using a relational database)
You security and roles needs will probably be met by Spring Security.
Here is the code of the Spring.io website which is a real world site using the latest Spring technologies.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
As a programmer with limited experience, and interest, in server management, what are some good options for having space available online that makes getting to the actual development and deployment of Java web applications simple?
Needs:
- ability to create, or at least manage a database through non-command line interface, even if it just requires using a remote connection to the database manager
- deployments can be done from remote server
- hooking up a domain to a Java server context needs to be easily done (I don't want to manage something like mod_jk with Apache manually)
It all depends on how cheap you want to go. Google App Engine is the cheapest (free) for small sites, but if your site gets very little traffic you have to wait for the JVM to start up.
Here are some links to check out:
Inexpensive VPS/Cloud:
http://www.joyent.com/services/cloudhosting/
http://performancehosting.net/hosting.php
http://www.godaddy.com/hosting/virtual-dedicated-servers.aspx
A little less expensive, but very popular:
http://aws.amazon.com/ec2/
If you are a Java dev and are interested in a very fun, simple Java-based web framework and hosting package:
http://www.playframework.org/
http://www.playapps.net/
More reading:
http://mediatemple.net/
http://www.rackspacecloud.com/
http://mor.ph/products
http://www.rightscale.com/
http://www.cloudfoundry.com/
Virtual Private Server (VPS) - rather cheap, prices start at around 13 dollars / month
Google App Engine (but it imposes some limitations)
Jelastic (Java Elastic) provides an advanced cloud hosting platform for Java developers. It simplifies provisioning of dev, test and production environments for simple and complex Java projects, automates horizontal scaling, load balancing and clustering. It also provides a unique vertical scaling which actually saves a lot of money and enables scalability for legacy applications that were not designed as microservices.
Another cheap option in addition to others already listed:
http://vpsland.com/windowsplans.html
http://vpsland.com/linux_vps_plans.php
If you are looking for something cheap and at the same time you would like to deploy in a simple way, you should take a look at some PaaS providers as they usually offer a free tier and they also permit you to deploy without installing or configuring any software in the user end. You just need to have your .war file and to deploy it.
Not all the PaaS support the same stacks. If you are only interested in a specialized java a PaaS a simple search with the key words "java platform as a service" will give interesting results.
You can use IBM Bluemix It has a 30 day free trial and after that you are charged for the time that your apps run and the memory that is used, calculated as GB-hours, so you only pay for what you use. Also there are a lot of tutorial about how to use Bluemix, here you can find a Java,Ajax and Cloudant (database) example: http://www.ibm.com/developerworks/java/library/j-hangman-app/index.html
Also check out Oxxus.net java hosting offers. They have java-ready VPS servers that come loaded with whatever JVM you want and also clustered solutions for scalability. They've been hosting java since 2003 and have no negative reviews online so it's worth checking out.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have not had much experience with Webservices or API's.
We have a website built on Oracle->Sun App Server->Java->Struts2 framework. We have a requirement to provide an API for our system. This API will be used by other systems outside of our system. API is just for a simple SP that we have on our database. The other system does not want to connect to our DB to gain access to the SP but instead and an API as a 'webservice'
Can the community please shed some light on how to go about this? Will the API be put on our webserver? is that how the other system will connect to it? And how to go about creating a public API?
Some things you'll need to think about are:
SOAP vs REST (Why would one use REST instead of SOAP based services?)
How will you handle authentication?
Does it need to scale?
You might want to take a look at https://jersey.dev.java.net/.
It would also be helpful to look at how another company does it, check http://www.flickr.com/services/api/ for some ideas.
If you are using the Sun App Server, it should be fairly trivial to make an EJB exposed as a web service with the #WebService tag, and then have that EJB call the Stored Proceedure and return the data. The app server gives you tools to publish a WSDL which is what they will use to know how to call you API.
That being said, what sounds easy at 50,000 feet is a real pain to deal with all the details. First, what about security? Second, are WebServices really required, or is there a better communication mechanism that is more obvious, such as (at a minimum) REST, if not some simple servlet communication. And the hardest part: In exactly what format will you return this result set?
Anyway, you could be dealing with a bit of a political football here ("what, you don't know how to do web services, everyone knows that, etc.") so it can be a bit hard to probe the requirements. The good news is that publishing a web service is pretty trivial in the latest Java EE (much easier than consuming one). The bad news is that the details will be a killer. I have seen experienced web service developers spend hours on namespace issues, for example.
Soap or Rest or .. is one side of the medal and depends on what the clients want.
The other (more) important thing is the api design itself. Shall it be stateless or stateful. Are clients co-located in the same VM (Appserver) or remote in the same LAN or even in a Wan.
As soon as the communication goes over the wire, it gets slow due to serialization. So you want API methods to obtain bigger (but not too big) chunks of data at a time.
Or in other words, your question can not really be answered without knowing a lot more about what you want and need to do.