One of the key design patterns needed to deploy a new, or migrate an existing, application to the cloud is robust session state management. This session state must be outside the business logic, and be able to scale independently of other layers.
Many existing architectures “bake it into the monolith” making it very hard to decompose software into smaller, more logical units—something sought after in these microservice oriented times!
Fortunately the Spring team realised that this is a common design need, and that having a robust, well tested, extensible and sophisticated session management layer than can be “dropped in” to your Java app would be incredibly useful. So they created Spring Session!
This week I am joined by Adib Saikali, a senior field engineer at Pivotal, who suggested we cover this topic during a fortunate meeting in a queue at Starbucks!
PLAY EPISODE #20
Resources
- Subscribe to this feed.
- Find more episodes of All Things Pivotal podcast.
- Feedback: podcast@pivotal.io
- Links Referred to in the Show:
Transcript
Simon Elisha:
Welcome to the All Things Pivotal podcast. The podcast at the intersection of agile, cloud, and big data. Stay tuned for regular updates, technical deep dives, architecture discussions, and interviews. Please share your feedback with us by emailing podcast@pivotal.io.
Hello everybody and welcome back to the All Things Pivotal podcast. Fantastic to have you back. My name is Simon Elisha CTO and director of field engineering here in beautiful Australia and New Zealand. I’m joined this week with a special guest. My guest is Adib Saikali who’s a senior field engineer at pivotal in our Toronto office. Welcome Adib.
Adib Saikali:
Thanks Simon. I wish it was as warm here as it is where you are.
Simon Elisha:
Yeah. I’m guessing there’s a bit of that white stuff on the ground or at least some pretty high chill factor going on there for you.
Adib Saikali:
Yeah. We’ve had the coldest February ever on record.
Simon Elisha:
Oh wow. So Adib and I had the good fortune to run into one another in much less cold San Francisco a few weeks back. In fact we were lining up in the Starbucks and we had a bit of a conversation. Adib was talking to me about a new project that our friends at Spring have brought out called spring session. We were talking about how … Some of the benefits and some of the improvements and some of the things people could use this for. We thought hey. We shouldn’t talk about this amongst ourselves we should share this with the listeners, so here we are. I wanted to kind of preface the conversation with why session management is important and some of the challenges of session management in the context of distributed architectures and cloud architectures.
Session state is hard for a lot of people to manage. Session state is important because if you think about how you interact with any application you need to keep some sort of temporal measure of where you are in any sort of interaction or process with that application. It’s as simple as if you take the sort of canonical checkout and shopping bag type scenario that we have where I put an item into my shopping cart and then I check out but I may not check out until later. I might go away from my machine. I may want to access it from multiple machines. All that state and session state has to be stored some where. In a non-distributed model or in an non-cloud model or in a non-scalable model we tend to get pretty monolithic about it. We just chuck it into a database somewhere. Or even worse keep the state local specific web servers that we are operating on etc. That’s really an anti-pattern in terms of scalability and reliability and all the other ‘ilities’ that we want to have.
So suddenly state becomes this important thing to consider. We need to manage it far more effectively. I’ve been advocating, way back for many years, that not having state anywhere near key components of your application but keeping it separate in a dedicated service in such a way that you can manage it, scale it, and access it very effectively. This is a very common problem. Adib, I think our friends over at Spring love to solve common problems, don’t you? What have they been doing in terms of spring session?
Adib Saikali:
Spring session is one of those projects that, when I saw it, I first thought, well why would they be doing this? I looked at it and I said, Wow. This is incredibly amazing. It’s amazing because we have a lot of applications out there that are coded, that are using the http session object, which is a part of enterprise java. We’re moving towards these more distributed architectures and we’d love to just be able to store our session automatically in some sort of common memory store, a memory grid of some kind. Perhaps redis. Perhaps gem fire. Perhaps something else.
When we look at the modern application we’ll see it’s not just one programming language in there. There are a lot of programming languages like, other than java, that people are building applications with. Maybe part of my app is written in java and part of it is written in something else. Perhaps .net. Perhaps ruby. Perhaps some other technology. But the state is still there and it’s a struggle for everybody to manage. What if we could, maybe, store some of that session state as json in memcacheD, or redis or whatnot. Wouldn’t it be great if we could get our java apps to read that without having to change the code? That’s the huge value that the Spring session brings to the table.
Simon Elisha:
Sounds pretty good, because it deals with a lot of the problems that we have in terms of state. Often many applications kind of rely on certain sessions connecting to certain instances of the application or doing some intelligent routing of traffic based on what session you’re in, etc. This is really a mechanism to break out of that model and enable your application to be much more scalable because that state is not baked in. It’s really running as a service itself to the application.
Adib Saikali:
Yeah, absolutely. The Spring team did a wonderful job of how they implemented it. All you got to do in order to use Spring session is drop the Spring session jars into your web application. Then you add a servelet filter to your servelet filters path. Make sure that all the requests first go through that filter. What that will do is it will activate the Spring session framework and you just keep using your regular http session. Whatever you write into it is going to go to the back end implementation of Spring session. By default you are going to get implementation for redis. It gets really quick documentation of how to implement your own backing store. Perhaps you want to use gemfire. Perhaps you want to use memcacheD or some other thing that you already have in your environment.
Simon Elisha:
Yeah. Suddenly it’s interesting having made that architecture quite pluggable, which is commendable in as much as that backing store can be whatever flavor you want. There are some pretty big ones. Obviously redis is probably a nice easy choice because it’s kind of battle tested on the internet as they say. We know it scales. We know it’s reliable. We know it’s well supported as well. Another nice thing that happens, and this is probably a little bridging to Spring session and cloud foundry, is it can leverage redis running on cloud foundry. Really it’s an interesting model where the Spring session code is very aware of where it’s being deployed, such that depending on the different platform it’s on it will deploy in different ways and access different services. Did you want to talk, maybe, a little bit about that process as to how it detects what’s going on at certain stages of the lifecycle?
Adib Saikali:
Sure. The best way to think about cloud foundry is how it detects things. We have this concept of services, the services bind themselves to applications. When you have Spring session starting up, it’s going to look for a redis service that it can bind itself to. Once it finds the redis service it will just use it. That’s kind of the high level way it works, without getting too much into the gory details which are hard to describe over audio.
Simon Elisha:
Yeah. It’s a pretty simply bonding mechanism and the thing I like is you can encapsulate it in the one manifest.yml file. It will just do it, which is what we like. We like things that just work on an ongoing basis. Now, if I’ve got an existing application and I’m looking at spring session what’s the migration path like. What are some of the thought processes I need to go to. What are some of the conscious decisions I need to make?
Adib Saikali:
Well I think the most important thing to look at is kind of like why are you doing it. What I find when talking to customers is that they’d like to move towards a micro services based architecture. They have some sort of application that they developed on a legacy java EE server and they want to start taking and breaking it up into functionality. Maybe start by slicing it up into, maybe the features in this jar go into one micro service. Feature in this jar go into another. There is still that dependency on the session. Most of the time it’s like who is logged in or some simple user preferences. With Spring session, in that case, the way you would use it is you would create a service and use redis as a backing store deployed to cloud foundry. Start just moving the code into separate war files and deploy those separately. Kind of gradually prove that there’s something that can work in that distributive fashion without having to truly write a lot of your code. Then give people the confidence to kind of, somewhat, cut the cord. To keep going further and further down the stack toward micro services. I see it as the halfway point or a step in the direction towards re-architecting micro services.
Simon Elisha:
That’s a great point. That’s a great point. It really is that’s that catalyst to decoupling the application so that you can move forward and can break things up and scale them out and separate them. It’s kind of like a gating item that you have to do. In the past it’s been quite challenging. I know when I’ve spoken to people about managing sessions, though it’s important, that’s all great but how do I do this easily. Well now we have this easy drop in frame work that we can use.
One of the other capabilities, and there’s many in this project which are really interesting, but one that I really like is the switching of profiles capability. I think if you are a Google mail user, for example, you probably have got multiple addresses for work, for home, what have you. You switch between them based on the context that you want. It’s a neat functionality and it’s actually natively built into Spring session which I really like. That means you can do quite intelligent session management for your application without some of the complexity that would normally go with the managing those different states and switching the between states etc. which is really nifty. Another interesting thing that, Adib, I’ll get you to talk about is the interaction with web sockets.
Adib Saikali:
Yeah. Web sockets is an interesting case. It’s because of the standard. If I have say a really simple gmail type application where maybe I have a little chat window, I’m sending messages back and forth over web socket and I’m logged into the application and I have an interesting tp session with the app. What ends up happening is that the web socket traffic doesn’t keep the http session alive. What Spring session can do for you, it allows you to keep the underlying http session alive and access it from within the Spring npc framework from the code that’s actually handling the web socket messages. That’s one way it works.
I want to go back, if possible, to the previous question about the profile switching because there is a use-case there that is like really relevant. Where I had to spend a lot of effort to implement. Which was I had an application that was sharing a lot of data and you could say who could see what data. We ran into this thing, requirement where by, okay I’m giving certain people access to certain data. I’d like to see the application the way somebody else sees the application. With Spring …
Simon Elisha:
It’s almost like personas.
Adib Saikali:
Exactly. Imagine you’re the CEO of a company. You’re sharing corporate data with different people and those different people that you’re sharing data with, you say this data is for share holders. This data is for employees. This data different things and you want to look at your whole application and say, what does it look like if I know I have the full super user powers, but what would a shareholder see if they were looking at my application. Being able to have another session where your personas and your state there isn’t what you normally have with all of the security provisions you have, but with some lower level of security is quite useful. That is traditionally quite hard to do without a lot of coding but with Spring session it’s significantly easier to do.
Simon Elisha:
Yeah that’s a great point. There’s a lot of logic trees and comparisons and testing that goes into implementing a feature and function like that. It has something that’s tried, tested, and open sourced to build off. It’s far more efficient than trying to recreate that wheel yourself. There is plenty of other wheels we can go and build, and we don’t have to go and build that one anymore. What else do people know about Spring session? Obviously we’ll link in the show notes to a really great blog post about how to use it and some code examples. Adib, you’ve been having a good experience with it. What would you like to pass on to the listeners?
Adib Saikali:
What I’d like to pass to them is a way of thinking about the problem. If you think about enterprise java, we started with these very large big large monolithic servers where we would say, you know what? That server can have ejbs running in it that are doing transactional code. It’s also got web servelets and jsp pages is doing the web rendering. It’s also got a jms server that’s built into it. Frankly to be a certified java EE server you’d have to have an implementation of all those things and a distributive transaction manager.
What we’ve seen over the last few years is that, in each one of those problem areas, be it like for example messaging, people prefer to run a separate messaging engine. Perhaps rabbitmq, perhaps something else. When it comes to distributive transactions you can just use distributive transaction manager on its own. When it comes to web rendering and http session management, those two problems were kind of traditionally in the same process. Which is interesting because it brings all sorts of problems around like I want to restart. I want to deploy new application logic but I don’t want to destroy the contents of my http session.
You look at popular apps, web containers like tomcat and you see there’s like a million different settings you can use to control the behavior of the session manager. When we really look at other frame works outside of the java space we find that they use a lot of memory grids like memcacheD, redis, and so on to store the http sessions. It is better because if I make a bug and I accidentally allocate a lot of memory, I could then end up using up, like starving, the session manager from having memory to store sessions in. Then you have to run multiple jvms, and you have to cluster them, and you have to replicate sessions between them. There’s frankly a limit to how much you get, how much gc you can have with a lot of the jvms. You don’t see a lot of people running a lot of jvms with a hundred gigs of ram.
Where as if you are running a native process, like redis, you could use up quite a lot of ram. Which is plentiful and cheap. You can locate it on the same machines that host your op server. You’ll really just be able to get a specialized tool that’s awesome at session management. You can start accessing that tool from your java code without having to rewrite code that you’ve spend years perfecting and testing. That’s what I love about Spring session.
Simon Elisha:
That’s great. Great point to make. It makes the shift really easy and gives you what you need to move forward with your application architecture. What we’ll do is we’ll provide some links in the show notes for those of you who want to follow up more and see some code and have a play with it. It’s there. It’s available. It’s been released. It’s all good to go. Adib, thank you so much for joining me today from all the way from Toronto. I’m sure our listeners have really enjoyed hearing from you today.
Adib Saikali:
Thanks very much Simon.
Simon Elisha:
Thanks everyone. Until next time tell everyone about the podcast. We do hope you like it. We do love getting your feedback. Got a few episodes lined up from user feedback coming up over the next few weeks. We’ll get on to those, but until then keep on building.
Thanks for listening to the All Things Pivotal podcast. If you enjoyed it please share it with others. We love hearing your feed back, so please send any comments or suggestions to podcast@pivotal.io.
About the Author
