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!

 

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.

Keycloak 1.0 Final Released

1 Comment

After 1 year of hard work, the team is proud to release our first final 1.0 release of Keycloak.  We’ve stabilized our database schemas, improved performance, and refactored our SPIs and you should be good to go!  I don’t want to list all the features, but check out our project website at http://keycloak.org for more information.  You can find our download links there as well as screen cast tutorials on our documentation page.

What’s Next?

Keycloak 1.1 will be our integration release where we start bringing Keycloak to different protocols, projects, and environments.  Here’s a priority list of what we’re tackling

  • SAML 2.0 – by merging with Picketlink IDP
  • Uberfire/BRMS adapter
  • Fuse FSW adapter
  • EAP 6.x and Wildfly console integration
  • Tomcat 7 adapter
  • …More planned, but we’ll see how fast we can move before we announce anymore

In parallel, we hope to look into a few new features:

  • Internationalization
  • TOTP Improvements like allowing multiple token generators
  • IP Filtering

Keycloak 1.0 RC 1 Released

Leave a comment

Many bugs fixes and cleanup.  Not much for features although we did add a ton of tooltips to the admin console.  We’re getting very close to a final release and are still on schedule to release 2nd week on September.

See keycloak.org for links to download and documentation.

Keycloak Beta 4 Released

2 Comments

After a summer of multiple vacations from various team members, we’re finally ready to release Keycloak 1.0 Beta 4.  There’s not a lot of new features in the release because we focused mainly on performance, creating new SPIs, refactoring code, improving usability, and lastly fixing bugs. 64 issues completed.  As usually go to the main keycloak.org page to find download links and to browse our documentation, release notes, or view our screencast tutorials.  Here are some of the highlights of the release:

  • Server side memory cache for all UI pages.
  • Cache-control settings for UI pages
  • Server side cache for all backend metadata: realms, applications, and users.
  • In-memory implementation for user sessions
  • New Federation SPI.  Gives you a lot of flexibility to federation external stores into Keycloak
  • Improved LDAP/Active Directory support
  • Token validation REST API
  • Support for HttpServletRequest.logout()
  • Lots and lots of bugs fixes and minor improvements

You should see a big performance increase with this release as everything is cachable in memory and the database can be fully bypassed.

1.0 Final is on the way!

What’s next for Keycloak?  This month we will be focusing on resolving the remaining issues logged in Jira, improving our test coverage, and updating our documentation and screencasts.  No new major features.  We’ll have a RC release around 3rd week of August, then our first Final release 2nd week of September!

 

Keycloak Beta-1 Released!

1 Comment

Keycloak Beta-1 has been released!  We’re edging closer to 1.0! Please visit the Keycloak website for links to documentation and downloads.  A lot of hard work the last few months by Stian, Marek, myself and other contributors to bring you loads of new features and improvements:

  • LDAP/Active Directory integration built on Picketlink.  Thanks Marek!
  • User Session management – can now view login IP address and which applications and oauth clients have open tokens.  Works with any type of app too.  Can view and manage sessions through user account pages or admin console
  • Audit log for important events.  Integration with admin console and ability to receive emails on certain events.
  • Account log viewable in user account management pages
  • Export database.  Allows you to export a full dump of keycloak database into an encrypted file.  Will help out tremendously to migrate between Keycloak versions.
  • Authentication SPI.  Allows you to plug in different mechanisms to retrieve and authenticate users.
  • Theme support for the admin console and any sent email.
  • Per-realm admin console.  You can now designate a user within a realm that is an admin of that realm.
  • Documented the Admin REST API finally.  (Docs still kinda suck here)
  • CORS support for Admin REST API
  • Improvements in Javascript adapter.  Including OpenID Connect session iframe style for single-sign out and support for Cordova.
  • Support for relative URLs when configuring admin console
  • Server configuration file
  • Social Only Logins
  • Installed application adapter
  • Expanded the number of example projects

What’s next? This is the last major feature release of Keycloak.  We will now be focusing on performance, clustering, security audits, testing, documentation, and usability for the next few releases.  We hope to release 1.0 Final sometime in July.

 

Keycloak SSO Released – Alpha 1

5 Comments

Keycloak is an SSO authentication server and appliance for securing web applications and RESTful web services.  After 7 months of hard work, the Keycloak team (Bill Burke, Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz) is proud to announce our first release, Alpha-1!  There’s still a lot to do, but there’s a lot you of features you can try out.  Besides written documentation, we’ve put together a bunch of video screencasts that you can view to learn and experience the features of Keycloak.

These are some of the core feature of Keycloak:

  • SSO and Single Log Out for browser applications
  • Social Broker. Enable Google, Facebook, Yahoo, Twitter social login with no code required.
  • Openshift Quick Start so you can deploy Keycloak on the cloud
  • Optional User Registration
  • Password and TOTP support (via Google Authenticator). Client cert auth coming soon.
  • Forgot password management
  • OAuth Bearer token auth for REST Services
  • Integrated Browser App to REST Service token propagation
  • OAuth Bearer token auth for REST Services
  • OAuth 2.0 Grant requests
  • CORS Support
  • CORS Web Origin management and validation
  • Completely centrally managed user and role mapping metadata. Minimal configuration at the application side
  • Admin Console for managing users, roles, role mappings, applications, user sessions, allowed CORS web origins, and OAuth clients.
  • Deployable as a WAR, appliance, or on Openshift.
  • Supports JBoss AS7, EAP 6.x, and Wildfly applications. Plans to support Node.js, RAILS, GRAILS, and other non-Java application

Go to the Keycloak website and follow the links to download, view documentation and videos, browse our source code, and submit bugs.

What’s Next?
As I said before, there’s still a lot to do, but here’s some things that will get in sooner rather than later:
  • Stan Silvert has written a Wildfly subsystem for Keycloak that didn’t get into the Alpha 1 release.  When we get this in, it will be super easy to secure web applications within a Wildfly environment.  You won’t have to crack open your WARs to add Keycloak configuration and enabling Keycloak security may be as easy as a doing a few clicks in the admin console.
  • Storage protection.  We’ll be adding support for more secure password hashing as well as storage encryption capabilities for the Keycloak database.  Its uber important to be able to have a 2nd level of defense for hacks.
  • Revocation policies. We need to be able to expire all tokens just in case somebody gets hacked and broadcast this information to deployed applications.
  • User session management.  This will allow you to view which users are logged in and give you the ability to log out one or more users.
  • Composite roles.  This will be the concept of a role group.  This will make it easier to change role mappings for a large set of users.

Thank You!

Finally, I want to give a huge thank you to everybody that helped make this release possible (Stian Thorgersen, Gabriel Cardoso, Viliam Rockai, Alexandre Mendonca, and Bolesław Dawidowicz).  Especially Stian for being such a great co-lead and Gabriel for doing such awesome design work.  This has been the best team I’ve been on since the good old JBoss Group days years and years ago, pre-aquisition when JBoss was young.

My new book! RESTful Java with JAX-RS 2.0

14 Comments

My 2nd edition of RESTful Java is out!  RESTful Java with JAX-RS 2.0 covers the spec additions to JAX-RS 2.0 including 3 new chapters:

  • JAX-RS 2.0 Client API
  • Asynchronous Client and Server APIs
  • Filters and Interceptors

The book has also been revised here and there to cover some of the smaller features that were added to JAX-RS 2.0 like ParamConverters, Link, an the extensions added to UriBuilder.  The workbook examples and chapters have been revised and expanded to cover this new content as well, so you really get 6 new chapters in total.    Many thanks  to Fernando Nasser, Melanie Yarborough, Meghan Blanchette, Meghan Connolly, and Charlie Roumeliotis for making this happen.  I’d also like to thank the JAX-RS 2.0 JSR Expert Group, especially Marek Potociar, Santiago Pericas-Geertsen, and Sergey Beryozkin.

 

Resteasy 3.0 Final Released!

1 Comment

Resteasy 3.0 has been released, follow links on the Resteasy web page to find downloads etc.  After sitting on the JAX-RS 2.0 JSR for two years and implementing it in the Resteasy master branch we’re finally ready to release!  I’d like to first thank the JAX-RS 2.0 JSR especially Marek, Santiago, and Sergey.  We butted heads a lot on the JSR and I could be difficult at times, but I think JAX-RS 2.0 is a great spec because of it. I’d also like to thank Weinan Li, Ron Sigal, and Gunnar Morling for fixing bugs and getting Bean Validation integration working in the last minute.

It is really really really important that you read the migration guide. We had to change a bunch of stuff and behavior because the JAX-RS 2.0 got really strict, specifically the request dispatch algorithm, so you really need to view it.  We also refactored some SPIs and such.  So, again, read the migration guide!

Features

  • JAX-RS 2.0 compliance.  Once Wildfly supports HTTP Digest Authentication we can officially certify Resteasy 3.0.Final.  Since this is really just red tape, I decided to release 3.0 now instead of waiting, weeks for another Wildfly release.
  • SSO and OAuth2 for browser and RESTful web services.  Built to work on AS7 and EAP 6.1, allows you to add these features on top of existing AS7 security domains
  • Bean Validation 1.1. integration support
  • More comprehensive generics support for all component types

Deprecated APIs

JAX-RS 2.0 standardized many features that existed in Resteasy 2.3.x and earlier.  Going forward we will not support these deprecated APIs in Resteasy 3.0.  They are there to ease your migration from proprietary Resteasy APIs to the JAX-RS 2.0 equivalent.  If you have a bug, you need to either provide a patch/pull request yourself, or upgrade to the JAX-RS 2.0 equivalent API.  As soon as Resteasy 3.0 gets into our commercial distribution, we will be removing these deprecated APIs from Resteasy, so you should switch sooner rather than later.

  • Resteasy Client API org.jboss.resteasy.client.ClientRequest etc.  Proxy API has been ported to work on top of JAX-RS 2.0 api.
  • Resteasy interceptor framework: MessageBodyReaderInterceptor, MessageBodyWriterIntereptor, PostProcessorInterceptor, etc… These all have JAX-RS 2.0 equivalents
  • Resteasy async API.  This also has a JAX-RS 2.0 equivalent

What’s Next?

Next few months we’ll be focusing on some point releases to mature 3.0.  I’ll also be finishing a revision of my O’Reilly JAX-RS book and you’ll see some new workbook examples in the distribution soon.  I’m also starting a new project that is going to pull in the OAuth2 work I’ve done.  More on that later though.  As for future Resteasy features, I’m looking for somebody to drive a RESTful database service interface.  If you’re interested, please ping me or our development list.

 

 

Older Entries