Quarkus Serverless Strategy

Leave a comment

What is Serverless?

Serverless architectures allow us to scale our services from zero instances to many based on request and event traffic.  The advantages are clear.  If our services are idle most of the day, why should we have to pay a cloud provider for a full day or waste scarce resources in our company’s private cloud?  Why should we have to plan for peak load when our architecture can scale up for this peak load automatically based on volume of incoming traffic?  Serverless solves these types of problems.

Function as a Service (FaaS) is also part of the Serverless paradigm and focuses on exposing one remote function per deployment.  It is a more fine grain approach than Microservices, with the idea being that you can be more agile at getting functionality to market with even smaller deployment.  AWS Lambda and Azure Functions are an example of FaaS implementations.   FaaS frameworks like AWS Lambda and Azure Functions not only bring autoscaling to your services, but they’ve started to make it much easier to deploy your code to the cloud.  In a Lambda or Azure environment, developers don’t worry about the container anymore and can just focus on pushing their code.  FaaS environments have started to take the “Ops” out of “DevOps”.

Java’s Disadvantages

Unless you’re focusing solely on batch processing, one of the disadvantages of a Serverless architecture is the instance spin up time.  In other words, the cold-start latency.  If you need milliseconds to response to a client request, and your service spinup is measured in seconds, then you have a problem.

Java frameworks like Spring, Hibernate, Microprofile, Java EE and other technologies traditionally have been slow to boot and even microservices written in these technologies take seconds to start up.  This is because most of these frameworks do all their configration and metadata processing at boot time.  Spring and Hibernate scan classes for annotations.  Hibernate additionally builds SQL queries.  They do the same exact pre-processing every single time they are spun up.

Java also has a huge memory problem.  If FaaS is the way to go and you’re having many more fine grain deployments, then Java based deployments are going to take up a huge amount of memory.  Some cloud environments also charge based on the memory used compounding the issue.

Quarkus Perfect Match for Serverless

Quarkus’s core values are to drastically reduce memory footprint and boot time for Java based applications and services.  There are two of the biggest concerns when dealing with Serverless architectures.  Quarkus has moved most of the pre-processing that frameworks like Spring and Hibernate do from boot time to build time.  This approach has drastically reduced service spin up and memory footprint.  Quarkus has also smoothed out the rough edges with Graal so that you can compile your Java microservices into native executables which provide even faster boot time and a lesser memory footprint than running with the JVM.

Quarkus Serverless Strategy

The Quarkus team is tackling Serverless in a variety of ways:

  • Enhance existing Serverless Java stacks out of the box
  • Bring the Java ecosystem to existing Serverless Java stacks
  • Provide portability between Serverless stacks through traditional, mature, existing Java APIs
  • Provide a new Java function API (Funqy) that is portable across Serverless providers

Quarkus Enhances Lambda

By modifying your pom and adding a few Quarkus AWS Lambda integration dependencies like the Quarkus maven plugin, you can compile your AWS Lambda Java projects into a native binary that the AWS Lambda Custom Runtime can consume.  Watch your cold-start latency and memory footprint drop dramatically.  Try it out yourself.

The idea here is to bring Graal support to AWS Lambda through Quarkus in a seemless way.  We have smoothed out the rough edges Graal introduces for a variety of AWS SDKs.

Pull in Java Ecosystem

Another part of the Quarkus Serverless strategy is to pull in the Java ecosystem into existing Serverless stacks.  Through Quarkus your AWS Lambda classes can inject service components via Spring DI or CDI.  You’re not stuck with using whatever AWS SDK provides and can use the mature Java frameworks you’ve been using for years.

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import org.springframework.beans.factory.annotation.Autowired;

public class GreetingLambda implements RequestHandler<String, String> {

    @Autowired
    GreetingService service;

    @Override
    public String handleRequest(String name, Context context) {
        return service.greeting(name);
    }
}

Avoid Vendor Lock-in

Let’s face it.  If you use AWS, Azure, or any other cloud provider SDKs, then you are locked into that platform.  If AWS jacks up their prices down the road, you’re going to have a tough time moving off their platform.  Quarkus helps alleviate this issue by providing integration between REST and HTTP frameworks like JAX-RS, Spring MVC, Servlet, and Vertx.Web with AWS Lambda and Azure Functions.  Let REST and HTTP be your portable architecture between cloud providers and avoid vendor lock-in by using REST frameworks that you’ve been using for years.  Try it out with AWS Lambda or Azure Functions.

One great thing about using our JAX-RS or Spring MVC support with AWS Lambda or Azure Functions is that you’re not stuck with one REST endpoint per deployment.  You can deploy existing microservices as one Lambda deployment if you desire.  This alleviates some of the management issues that an explosion of function deployments might create down the road as you can aggregate as many endpoints as you want into one Lambda deployment.

Funqy Cross Platform Functions

The final piece of our Quarkus Serverless Strategy is a new cross-platform function API called Funqy.  Quarkus Funqy is a simple API that allows you to write functions that are usable in a variety of FaaS environment:  AWS Lambda, Azure Functions, Knative Events, and more.

public class MyClass {
   @Funq
   public MyOutput myFunction(MyInput input) {
     ...
   }
}

Funqy is still in development.  We’ll have a follow up blog as soon as it is ready to release.

More to come

Quarkus will continue to revise and expand our Serverless Strategy.  Come try out our integrations and new APIs.

Quarkus unifies reactive and imperative for REST

Leave a comment

The latest release of Quarkus has unified Vert.x Web, Servlet (Undertow), and JAX-RS (Resteasy) under one I/O abstraction.  Specifically, Servlet and JAX-RS were written on top of Vert.x.

What this means for you is that if you are using Vert.x, Servlet, and/or JAX-RS in one application they will all share the same io and worker thread pools.  Scarce resources are now reused.  Because everything is unified under Vert.x, there’s a lot of future optimizations and features that we can bring to Resteasy and the JAX-RS coding model.  More info on this coming soon!

 

Deflate this!

Leave a comment

Got to see Bill DeCoste this week at DevNation and we relived some of our Superbowl memories. Here’s some pix
FullSizeRender
IMG_3825IMG_1596
bb-6-rings

Ring ceremony was awhile ago, but I just love this picture.  The guy has 6 bleeping rings!  BTW, somebody asked me if I was at this ring ceremony…LOL!  NO!  I just love this picture I found of Vince and Bill!

HTTP Quote of the day

Leave a comment

“T]hose who do not understand HTTP are doomed to re-implement it on top of itself

I wonder how many of us have done this?  I know I did a few times when I first started writing REST-based services.

Keycloak 1.1.0.Beta2 Released: Adapters, Proxy, Wildfly Subsystem

Leave a comment

A lot of new features this release.

  • Tomcat 6, 7, and 8 adapters
  • Jetty 8.1, 9.1, and 9.2 adapters
  • HTTP Security Proxy for platforms that don’t have an adapter based on Undertow.
  • Wildfly subsystem for auth server.  Allows you to run keycloak in domain mode to make it easier to run in a cluster.

Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org for more details.

Keycloak 1.1.Beta 1 Released: SAML, Clustering, Tomcat 7

Leave a comment

(Copied from Stian’s announcement) Pretty big feature release:
  • SAML 2.0 support.  Keycloak already supports OpenID Connect, but with this release we’re also introducing support for SAML 2.0.  We did this by pulling in and building on top of Picketlink’s SAML libraries.
  • Vastly improved clustering support.  We’ve also significantly improved our clustering support, for the server and application adapters. The server can now be configured to use an invalidation cache for realm meta-data and user profiles, while user-sessions can be stored in a distributed cache allowing for both increased scalability and availability. Application adapters can be configured for either sticky-session or stateless if sticky-sessions are not available. We’ve also added support for nodes to dynamically register with Keycloak to receive for example logout notifications.
  • Adapter multi-tenancy support.  Thanks to Juraci Paixão Kröhling we now have multi-tenancy support in application adapters. His contribution makes it easy to use more than one realm for a single application. It’s up to you to decide which realm is used for a request, but this could for example be depending on domain name or context-path. For anyone interested in this feature there’s a simple example that shows how to get started.
  • Tomcat 7 Adapter.  A while back Davide Ungari contributed a Tomcat 7 application adapter for Keycloak, but we haven’t had time to document, test and make it a supported adapter until now.
What’s next?
The next release of Keycloak should see the introduction of more application adapters, with support for JBoss BRMS, JBoss Fuse, UberFire, Hawt.io and Jetty.
For a complete list of all features and fixes for this release check out JIRA.
I’d like to especially thank all external contributors, please keep contributing! For everyone wanting to contribute Keycloak don’t hesitate, it’s easy to get started and we’re here to help if you need any pointers.

Resteasy 3.0.9 Released

Leave a comment

I really want to thank Ron Sigal, Weinan Li, and the rest of the Resteasy community for having my back the last 5 months while I was focused on other things.  Thanks for your hard work and patience.  3.0.9.Final is a maintenance release.  There are a few minor migration notes you should read before you upgrade, but most applications shouldn’t be affected.  We’ll try and do another maintenance release in like 6-8 weeks.  Check out resteasy.jboss.org for download links, jira release notes, and documentation.

Older Entries

%d bloggers like this: