Is it recommended to deploy spring micro services on Lambda. I have recently deployed a sample spring boot app returning a sample data from AWS RDS Oracle DB on Lambda, Just analyzing the possibility if we could deploy two micro services in different Lambda functions and configure them using API gateway.
I am entirely new to it and trying to understand if Lambda can really support micro services patterns like Service discovery/Circuit breaker or Saga patterns if I deploy two or more services on different lambda functions. Would Lambda be used for such scenarios in Real Time ?
Can anyone help me if there would be limitations other than package/payload size limit or timeout limitations ?
Thanks in Advance
If you use java for serverless application like AWS lambdas I would recommend for looking a framework which supports Ahead-of-Time compilation which will boost a lot your application start. If your application is not bit it will be very easy to be rewritten with Micronaut (very similar to Spring boot development)
For instance have a look at Micronaut, Quarkus using with Graalvm. Spring Boot is not the best option using with directly with AWS lambdas, it is big package size + really a lot of initial time, not good for API services.
Target of max package sizes of 25 MB for small cold start with adjustable memory starting from 256MB, with spring boot this is not doable.
In case you are referring to Spring Boot Cloud Functions that's exactly they were made for.
Google Cloud Functions already have an Alpha product for running Java functions.
AWS Lambda seems to have support for this as well.
In case you simply wrote a Spring Boot app with embedded Tomcat that you packaged in a Docker container which you're spinning up on demand, beware that cold start can be an issue, especially with the overhead of the Tomcat.
Related
I would like a solution that allows to manage json objects, calls to SOAP services and access to the DB via Spring data on a set of lambda services.
But on the net I read that lambda functions should be very simple.
Maybe Spring cloud is the solution?
Regards
In my opinion Spring Boot isn't a good technology choice for AWS Lambda but it's possible. The best way to start using it is to checkout the different wrappers and helpers in aws-serverless-java-container. There is also a good blog post about Spring Cloud Functions on AWS Lambda if that's interesting to you.
The internet tells you that Lambda functions should be simple because then they're easier to scale. If you create another monolith using Spring Boot on top of AWS Lambda, then this is not what AWS Lambda should be used for.
Below I'm listing advantages and disadvantages of using Spring Boot in AWS Lambda. There are probably more but these are the first ones that came to my mind.
Advantages
You can setup an API Gateway with proxy integration to AWS Lambda and then handle all the REST endpoints like you're used to with Spring Boot.
You don't have to manage your instances because AWS Lambda is doing that for you.
As soon as one Lambda function instance has started a Spring Boot container, this function will respond in a consistent way in terms of performance as expected from Java (at least that's my experience with Java Lambda functions).
Disadvantages
More complexity because you need to map an API Gateway event to an HTTP event that Spring Boot can handle. That's what the wrappers mentioned above already do for you.
A longer cold start time for your Lambda functions because Spring Boot is too slow to startup quickly like it's expected from Lambda functions. This means, you'll have spikes in your response times when a new Lambda function instance is started. If this is unacceptable, then don't choose Spring Boot with AWS Lambda.
You'll have multiple Spring Boot containers running without much control because AWS Lambda spins up instances if they are needed. You can control the max and min number of instances, but that's it.
Making SQL queries from AWS Lambda can be a pain due to the uncontrollable number of instances. You might run out of connections quite quickly if a spike hits your Lambda functions because it spins up more and more instances.
Having said that, I have used Java Lambda functions in the past and it is great to run them in the background doing some data processing. However, I'm not convinced that they are a good choice for "customer facing" endpoints like a REST API (except if you keep a minimum of Lambda instances running but then you can question if AWS Lambda is the right choice for you).
I would like to port my Java Spring application to run in AWS Lambda. Is it possible? Are there any resources you could point me to? There are some tutorials available for Express, but not for Java Spring applications. Would greatly appreciate your help.
AWS Lambda is serverless and have limitation to upload binary and max execution time is 15 min.
You really not need Spring or any other framwork to run lambda as its working on own framwork
Plz share your usecase why need sparing with Lambda
I am trying to learn and create a microservice using Spring Cloud. I am using Spring mvc and Spring Boot for development. I added separate Spring Boot application for both Eureka server and Zuul client. I have three Spring Boot application now. One Sureka server, one for Zuul routing and third one is for my microservice application. I run the Eureka server and the microservice and Zuul found to be running properly in Eureka server UI.
My doubt is that, I am planned to use routing and service discovery in my microservice. So I have a total of three Spring Boot applications. Can I deploy these three applications into AWS Elastic Beanstalk?
When I exploring I found that Pivotal Cloud Foundry topic. Since I am planing to use AWS Elastic Beanstalk. So what is the role of Pivotal Cloud Foundry in my application?
I am still confused about microservice development using Spring Cloud.
So there are two elements in your confusion. Is Amazon Beanstalk suitable?
So answer is yes. but you have overhead of orchestrating various services of amazon over then. Basically Amazon Elastic Beanstalk is more form based which means you need to tell what exactly you want to do with application for example route setup , scaling mechanism , application portability, application health management , Integration with external log aggregators etc. This is big learning curve to many people (including me :) ). Where as these with PCF these things are easy and straightforward and sometimes implicitly done.
Now Can I use pivotal cloud foundry with amazon? answer will be absolutely yes.
Pivotal cloud foundry is Wrapper written over open source Cloud Foundry project.
It is more succinct PaaS option than Amazon Beanstalk. You can host PCF on amazon ec2 ( IaaS )boxes using BOSH software. To answer you PCF is a alternative to Amazon Beanstalk. You don't need PCF is you want to use Amazon Beanstalk and vice versa.
I'm confused with cloud/clustering technologies like Docker Swarm and Spring Cloud and how they relates to each other.
Is it correct way to thing, they implement same functionality at different layers? For example docker swarm performs load balancing and service discovery at container or network layer (application is agnostic of this layer), where as framework like Spring Cloud embeds this logic to application, giving more flexibility, but also violating separation of concerns.
Am I mistaken, or is this correct? What is the SWOT of each approach, and is there any reason to use both Docker tooling and Spring Cloud utilities together?
First off, Spring and Docker are two different technologies coming from different points of view. From what I can gather, Spring Cloud is a mechanism for deploying java containers and orchestrating them.
Docker is an application / OS agnostic deployment mechanism.
I don't know much about Spring Cloud, but if you're in an environment that is not all Java, it may make more sense to approach Docker. It would allow you to deploy micro services on just about any platform.
We went through this at the last company I worked for, as they were implementing Springboot, but also looking at Docker at the same time. In the end it just made sense to deploy everything in Docker since it provided a uniform deployment and service management mechanism. That as opposed to hobbling together various deployment and management tools by language.
I am trying to get the idea of cloud serves but didn't get the point of that.
Dose it can replace a server for the app?
what is the purpose of it?
I have an android app and I what to get info from the server can it be done with Cloud Foundry and what is spring and how it connects to Cloud Foundry.
If you can give me link of how to communicate android app with Cloud Foundry
thanks a lot!
CloudFoundry's an open-source PaaS (github.com/cloudfoundry). It commoditizes the stack - that is, in practical terms, it makes it dead simple to get things like databases (MySQL, PostgreSQL, Redis, MongoDB), messaging (RabbitMQ), and web servers (Tomcat) up and running quickly. Whereas clouds like AWS let you spin up CPUs and hard disks and a stock OS install, a PaaS like CloudFoundry lets you spin up infrastructure, like message brokers, databases, and web servers and routers. So, yes, it replaces a server (or, often more importantly, it can stand in for 1000 servers on-demand). That's the obvious part.
CloudFoundry itself is open source, so unlike other PaaS solutions, by building on top of CF you're not locked into CF. You can later decide to run the cloud locally on your own datacenter, or on some other CloudFoundry provider (CloudFoundry.com is just one provider of the CloudFoundry software. Just as you can easily re-target a git repisotry to have it point to any remote repository using the git command line tool, you can re-target the CloudFoundry 'vmc' command line tool to point to a different CloudFoundry install.
Spring's a development framework in Java. It's not the only way to consume CF, but I personally think it's quite nice. CF exposes a lot of different technologies for the eager technologist and Spring provides the only comprehensive library set that can handle all those options. Learn one Spring library and the others will feel simialar, and so it's more natural to get started with a new API and technology. In the way that APIs designed with idiomatic Python APIs are said to be "Pythonic," Spring's APIs are cohesive and work nicely together. However, if Java's not your cup of tea (punny!), then that's OK too. CloudFoundry supports Ruby on Rails, Scala, Node.js, and other cloudfoundry providers support alternatives (Stacato supports Python, AppFog supports PHP, etc.)
For a quick example demonstrating how to get started with Spring, and the SpringSource Tool Suite, and a development virtual machine for CloudFoundry (so you can develop locally and quickly), check out this blog (and, particularly, the video embedded therein): http://blog.springsource.com/2011/08/24/micro-cloud-foundry-for-spring-developers/
The Springsource team has been doing some interesting work this year integrating a variety of Spring projects with Cloud Foundry.
With the rising popularity of microservices, many of the Spring projects are proving to be useful not only for quickly developing these smaller, lighter weight services, but also for easily incorporating some of the projects from Netflix OSS that implement patterns for making them industrial strength even at web scale.
A few related links:
The latest Cloud Foundry Java buildpacks include support for Spring
Boot and Spring Auto-reconfig (https://github.com/cloudfoundry/java-buildpack/releases).
The CF docs
contain an example on deploying Spring Boot apps to Cloud Foundry or
Heroku
The new Spring Cloud project will "Integrate your application with Pivotal Cloudfoundry. Makes it easy to implement SSO and OAuth2 protected resources, and also to create a Cloudfoundry service broker."
I look forward to seeing more of the results from the collaboration between the Cloud Foundry and Spring teams. One evidence of this is a recent tweet from Pivotal's James Watters "As the Microservices trends take off its pretty amazing to have the world's leading lightwieght #springframework on same team as CF."