This week I sit with Rohit and we continue our discussion of his 10 step process for Microservice API design.
Michael C.: You’re listening to the No Fluff Just Stuff podcast. This week I am joined again with Rohit. We were talking about his ten step process for enterprise architecture and microservice architecture. And we’re going to be going through the second five points. So thank you for joining us again, Rohit, and hello. How are you?
Rohit B.: Well, I’m glad to have back here, and this is our second session. Well. The first session, as we discussed, you know we started with the pain point of all the applications when we start working on it is we have a monolithic app and we already have the conception model defined and our use case is defined and what we do is we just try to mold the application into the cloud native application. That’s probably not the best way to do it and that actually sprang me to look at all the aspect of the rest APIs, how should we design it for the cloud so that they are more performance.
Michael C.: And that’s really going to dovetail really nicely into point six so I just want to put a little point in that to cover through the other points here. We talked about defining use cases, consistency, availability and being partition tolerant. The ideal design, the ideal naming conventions and going through the process to think through and find the fail points ideally before they happen. Do you have anything you wanted to add to those five points there so far?
Rohit B.: Oh, yeah, so I think the important thing here is we have to realize that our API design aspect is agile process, try to keep it simple. Try to think through evolutionarily how you want to build the application. Make sure you have a use case that you’re supporting. If the use case is saying that I need 100 concrete users and it needs a thru port of less than 200 milliseconds that’s a separate design model.
Then if you have got only 20 users who are going to use your application, you might not want to bring that application as a microservice or cloud native app initially but as we discussed the important thing is no matter how your application has been built so far, you build your creative façade layer based on that particular façade layer because you already have an ideal design. The ideal design to solve your use cases problems, then you can hook up using proxies to your old codes until the time you are preparing your team to move to the next step so I would take a face approach here instead of saying, okay, we’re going to take the whole elephant and bite at the same time.
It would never work. You will have to pick your battles, pick the areas which are really important for you. Where you’re getting a business ROI.
Michael C.: Yeah, where you’re getting the most value.
Rohit B.: Where you’re getting the most value out of it and that basically drives and that becomes your API gateway for the world and why is it important to build the API gateway and that’s the most critical part which people miss out is that if you have your API gateway, that’s the pathway fro others to build for you. We never think that way. We say that, “I got to build everything myself. I have my application. I have to build myself. There is no crowd sourcing going on,” and that model is changing in cloud native world.
What’s really happening in Uber, if you go to Uber, now other applications are tying up to Uber and building their application on top of it.
Michael C.: I’ve been seeing this lately with the google maps for example. I do a route from A to B, maybe looking at the public transit options and it comes up and says you know there’s another option here that only takes seven minutes and it’ll cost you about 11 dollars and you know tap here to hail an Uber.
Rohit B.: Exactly. And not only that, like nowadays … for example trip advisor, you’re building your trip. You’re just going from one place to another place and you’re moving around and you’re going to one city and then go to another city. Now what happens if something fails?
Now we need to think through this. What if the flight got delayed? It’s perfectly fine because trip advisor already knows the flight got delayed and it would call the Uber at the time when you really need it. Instead of me figuring out, oh, how am I going to go from my place to my hotel, this has already been figured out by interfacing of those applications and that’s where I was coming from, ideal design perspective.
Once you have that design, an extensible design. Now other people can work on top of it. That’s the key part here. You want to make sure that you are building your application so using integration hub, design patterns or other design patterns which are available for integration, you can integrate, extend your application so that other people can work on it.
For example, you know, amazon has Alexa. You can just order Uber to Alexa. I need an Uber to go here. Okay, Uber is right outside your door. It’s a very simple concept but it’s like a lot of companies are coming up with these kind of concept to give the real quality for the pain point which are going to come up.
That’s why I was spending most of my time in the pain points. Once you identify the failure points, you know what the most amount of time the architects should spend or the business owner should spend is where is the failure point coming in?
The golden nugget is in the failure point because if there is a failure point, if you’re providing an interface to provide your microservice solution or rest API solution for that, that’s going to give you bang for the buck and that’s what happens, like most of the companies that build on top of the currently infrastructure in the health care, in the retail, they all solve those failure points.
Similarly those companies have to revive themselves for cloud native application which has to be available most of the time. They have to be available. They have to be responsive. They have to be failure proof. If they want to scale, they have to be failure proof.
Michael C.: I want to talk a little bit about failures because it seems like in our industry there’s a general trend that there’s a lot of developers, there’s a preponderance of developers at least that really are great at thinking through the happy path right, when everything just works, and moving into an architectural you definitely have to be more aware of all these edge cases, all these potential failure points. Do you have any advice on how to develop that skill? Because I really do believe it’s a skill.
Rohit B.: It’s actually true. The failure point is not just from the [materialogy 00:07:03] perspective I have one point for that but there’s another point which is called, you have to do trade modeling on the same aspect of it. Like from architecture perspective you have to look at how your application has been called from different people and that would actually come up with and there are told that are available, you know, Microsoft trade modeling is available which is free of cost. You can just download it and start using that. It’ll give you problems like spoofing which could happen anywhere when you’re trying to use your application.
Somebody’s calling your application. Can they spoof your data? And those kind of things you have to find out early in your process and if you find a failure that whole process starts from step number one. That means, you have defined a failure problem. Lets take one example that makes it very concrete for this case. For example, Uber, when they earlier started working on their application, they were still a monolithic app. They were trying to build their application. They were doing analytics as well as providing all the support for their customers so they had pretty much like a two trunk approach was there.
The first thing what they did was they came in and say, “okay, maybe we want to separate this thing out. Analytics can be done separately and real time analysis can be done separately,” so they break that into two parts and then they found out that okay, somebody wants a ride. So what happens when somebody wants a ride?
They actually send a text or a message to other people who are waiting for that ride, so the driver picks up, say, “okay I can take this ride.” At the same time they want to send that same message to the consumer saying okay, “this driver is this much rating is there” and why they put in the rating? If you think about it, they put in the rating because people need to be comfortable sitting in a car and you know, that’s the kind of motion of social responsibility which comes in here to solve a particular problem and they solved this problem saying that okay, some drivers were rude and that was causing a problem.
Michael C.: And it creates a negative impression on the platform as a whole.
Rohit B.: As a whole, and that’s another thing which comes in, so they found all their problem, nugget, golden nugget they found and then they created a rating system on top of it. Not only they created the rating system for the drivers but also for the passengers. You think about that, you are also getting rated.
There is a lady who said, “hey by the way nobody’s accepting. Nobody’s coming toward me to pick me up.” Somebody told, you have a bad rating. You have to improve your rating, so that’s the kind of failure point model they come up with. Another problem they had, that can happen with any other company in the similar kind of situations, when the car is arriving there was a lot of wait time. You have to wait for ten minutes. And that’s a failure point.
If they have to wait for ten minutes for any passenger to arrive, it’s not good for their time to set to the destination.
Michael C.: That’s costing them money.
Rohit B.: Costing them money.
Michael C.: The other flip situation of that I noticed that started happening at O’Hare at least. I don’t know if I’ve seen this at other airports but during busy periods, the dispatch actually tells the next driver in the queue or the dispatch application tells the next driver in the queue, go ahead and start driving to the terminal and so they leave, because their holding area is wherever it is, one or two miles away from the actual terminal.
And it says, go ahead and start driving to the terminal and between now and there you’re going to get a ride. That was a huge change. Instead of getting out. Okay now I’m on the curb. Now I’m going to hail a ride. Now I’ve got to wait for them to go through the tollbooth and everything else that they’re already basically right around the corner when I press the button and then they get the ride and they know that there’s so much demand now that they can …
Rohit B.: That’s the customer service perspective. That’s the key part. What do we do in this case? The person is taking ten minutes to come in. You send a text message to that person, and that’s what they did. That was one of the failure points. They send a text message to that person saying that, “hey the car will only wait for two minutes. If it’s more than two minutes the clock starts.”
That means they’re paying for the money, their idle time they’re paying for it. And this message is being sent like a few times to the people so that’s just one failure point which is there. Similarly, you might have a failure point on another service which is just a cash service. You are getting something from the … get the customer information. Now, if you’re calling the same customer again and again it’s a good idea to cash that on your side and have a mostly center used cash and that’s the model using [reddis 00:12:00], cash model and that’s the design pattern which are coming in to solve all these failure point which can happen along the way to solve that problem.
Michael C.: In terms of the threat in modeling though aspect of it, you mentioned some tools but what are some other approaches? Threat modeling, especially around security is an area that historically we’ve been really bad at. That we don’t, we don’t think of the security aspect and a lot of times the business pressure is well, we can patch that in the future release. We just want to get this idea coded up real quick and out to the market and now we have IOT devices attacking, performing DDOS attacks and we have vulnerabilities that really shouldn’t be a thing anymore that are almost everywhere.
Rohit B.: Exactly and that’s actually another talk which I gave for the OS top ten. The key part here is input validation and output validation. If you just focus on these two aspect of it. No matter from where the data is coming from, do not assume the data is correct. Do not assume is the data, whatever you are sending you can send directly to the database because I have done for myself, from learning perspective, we have looked at my own application and some other applications where I’m able to do sequel injection. I’m able to find out the username, password. Pretty easy to do those things and the important thing is the input validation.
How can I scrub the data so when it comes to me, it does not have any script in it. The class site scripting which we want to make we don’t do, we protect ourself from that. All those things have to be part of our first line of defense when we create our APIs so that cannot be handled by just providing a common layer support for security. That’s just one part of the security. The input, whatever is coming in, that has to be scrubbed. It has to make sure that whose calling it is very important.
Sometimes what happens, you get authenticated but you get authenticated as a user because you’re authenticated as a user, you should only be able to do whatever the user can do.
Michael C.: Now we’re talking about the distinctions between authentication and authorization which a lot of people seem to use interchangeably.
Rohit B.: Exactly. I mean we think that we didn’t authenticate the user, we are all set but if you think about from the rest API perspective. You might have few operations for that rest API which cannot be performed by a simple user. Only admin can perform that. For example, getting the base salary. Getting some of the values which are coming through from there.
It’s the same object. It’s the same person object which is the return but base pay? Probably not. You don’t want to send that. Same thing too, social security number. Social security number, there is a law, you know [Pepda 00:15:16] personal information law in Canada and I’ve got Graham [lebeed biliac 00:15:24] here and then health care HEPA, they’re all providing and you have to look at all of them and say, okay, I’m signing this data out and the data is going through. Data is just not addressed.
Michael C.: So the, speaking a little more to your point, number seven in your process around security and threat modeling, do you think it is necessary vital or optional for an architect to work with some kind of security focused person in an organization. Or to have somebody in a security role.
Rohit B.: Absolutely, security is part of a ninja direction. You have to have security ninjas within your group itself, which represent your area, and they’re basically not just looking the data, whichever is stored. We think that the data needs to be stored securely. That’s the main part which we try to do. We’re always trying to look at a data perspective.
Data can be addressed, data can be motion, data can be transformed, so you have to make sure how the data can be used. All those places are securities essential, when you’re solving the problem.
Michael C.: Have you heard of this concept of a red team? A red team in an organization, their job might be to play devils advocate. Their job might be to break the security of an application. Their job is to kind of, maybe take on a white hat type of role on certain projects. Do you think that’s a useful thing for organizations to explore?
Rohit B.: That’s the model which I was coming up with, when I said you know, we need to have a team which solves a problem, that’s a security ninja model where you have probably ten or 15 security ninjas and you have some time frame. For example, we did in our company, where you’re doing a security threat analysis and you’re going through all the analysis and finding out results. There are tools which are available which can help you out with those kind of aspects when you’re building your security model in place for you.
But that does not end just there. You have to make sure that you are use industry standards for security. You should use [SAML 00:17:46] authentication. Mark up language for that and open heart so that when you are not alone. If you think you’re the only application in the world, you’re going to interface with not really. You will be interfacing with other vendors and there are acquisitions which take place and you have to have a value proposition in place where you can interface with anybody.
That’s the direction the data industry is going. You need to support open heart security models and also …
Michael C.: NWT yeah.
Rohit B.: NWT. So NWT is another good way of lightweight, if you don’t want to go become that heavy weight you can be lightweight when you are basically using within your application and outside application also and it basically gives you a good way of controlling who has access to what at a given time so I would advocate these two are the good models to go with this.
Michael C.: Okay. Moving on a little bit from security, the other really big challenges that I’ve seen quite a bit and I’ve seen a lot of people get it wrong, is the whole notion of API versioning, you know, so you talked a little bit in the last episode that these are agile architectures. This is an evolutionary approach, it’s not a big bang now we’re microservice compliant. It’s really more of the, this is a long term evolutionary process and so it is inevitable that our APIs are going to change.
I know Brian [Zletten 00:19:22] who’s very knowledgeable about rest and the web is very adamant that you shouldn’t be versioning your API in the URI, that it’s conflating representation and identity. Or I forget exactly how he phrased it but it’s something that we have to do. What is the right way to version your API? Understanding that it’s inevitable. I assume it’s inevitable. What are your thoughts on that?
Rohit B.: Yeah, if you just think about versioning part of your customer, whenever we build some API it’s on the agile principal. They are going to change. The requirements are going to change and they need, we need for the existing customer to still be able to perform. Without impacting our new changes which are coming through and important notion here, thy shall not break existing customers.
Michael C.: Absolutely. Do you have thoughts on how to do that if you’re not putting the API version? My company, API.mycompany.com/V2/ because that’s not technically truly representative anymore.
Rohit B.: Yeah, so I mean, if you think about the history of how the APIs got started, a lot of people start using URI part. There are four methods which you can use for the API versioning. URI part is where you’re putting in version as part of your company, you’re saying V2 and then the user and then you’re providing the support for that and that’s being used by twitter. That’s been used by [Aldashin 00:21:06]. That’s been used by [Deggae 00:21:09]. A lot of the people, 2008, 2007, 2008 time frame and they were coming up with these design.
That was very popular because that was the only good way of doing this.
Michael C.: Course that was a decade ago now.
Rohit B.: Exactly, and then now that’s what happened that you know, when we have versioning as part of our model, the advantage here is that the simple aggregation you just have a newer version coming out. But if you think from the client perspective, they have the most amount of pain. What do they need to do when they want to move from one version to another version? They have to change. They have to change all their code to use the newer version which is coming out.
That used to be the model initially which we used to do but not anymore, so I would not … I’m not advocate to move towards that direction. And then, the other aspect of it, that URI parameters. And a lot of companies do that and it depends upon your use case what you’re trying to solve here. What they’re saying is for example Netflix does that. Google also does the same way where you have the URI as a parameter.
Michael C.: As a query string parameter so it would be objects, action or noun, verb, question mark. V 1.1.
Rohit B.: Exactly, 1.1 1.2 kind of thing, so why are they doing that because what they’re saying that hey, if you’re not putting in the question mark V and then the version, you’ll always use the latest version. Kind of if you think about from agile development process, if you make your application test driven where you’re always making sure that the contract is being maintained and then in that case you will always be backward compatible. That’s where automation comes in and we’ll talk about the automation later on.
But it gives you an understanding that if you want to go towards this model, it’s kind of useful if you are guaranteeing that the same API will be supported for the near future. If that’s not the case, then in that case you might want to … because it’s kind of surprise. If you think about it, it’s a good thing. Without version change, always you get the latest version, it’s a really good thing for them but if you think about it that what can happen for the developers. What can happen for the clients.
They can be surprised with the changes coming in.
Michael C.: Well especially if it’s a breaking change.
Rohit B.: If it’s a breaking change, that’s a bigger problem. You then have to create a new one. That’s what people do. Oh let me add a new end point. Let me add one more end point for this. Oh it’s doing pretty much the same thing. No no no I don’t know want to break my existing customers so those things come in where you have to still satisfy them providing them with optional parameters to really make the API still work. That’s another model, a lot of companies are using it, but with all these models the problem is that when you put hypermedia on top of it, if you support with LSND and if you are providing the support with that and now if you think about it, you’re versioning how they’re using their system.
When you release another version, it’ll be V2. Another version it’ll be V3. How would they cope of that versioning mechanism in the file of the when we are using hypermedia control? That means, lets say for example, amazon. Amazon always you’re looking at a product. It’s have the buy signal, but you may also be interested in buying these items.
If those versioning for those item changes or there’s another version being added or another item added the client has to change to make sure that the new version is also supported from there, so they have to support the old version. They have to support the new version so that’s the problem which comes into integrates and supporting this kind of behavior where you have to solve that problem.
To solve that, one of the aspects they are using is content negotiation. When you say content negotiation you’re just saying that for your application, I’m using version three for my application for this entity.
Michael C.: And you’re doing that in the headers of the request.
Rohit B.: Yeah, they’re all done as part of the headers of the request so when you’re using that way, now that has some complexity but if you think about it from the user’s perspective, there is so code change. Code remains pretty much the same. Only thing is when you’re using that, when they’re is a new version which comes in, then the newer version somebody else is using version one. They’ll keep on working with version one. Someone else use version two. You can add more parameters to your rest APIs and that would also be supported through this particular model without any problem.
It has a great benefit from the client perspective. Of course it has some complexities as you see, for you would have to use it as part of the header information for this one. But it’s a good model to use if you want to change.
Michael C.: Would you say that that’s the current best practice out of all of the options?
Rohit B.: Yeah. Well, that’s one of them. There’s another one called custom header so custom header where you’re putting, you say my application version is so and so. You’re just putting it as part of the custom header.
Michael C.: So to clarify those two options. The content negotiation, you’re actually sending an explicit accept header that I would accept content texts say on API whatever. That’s actually being, when you’re negotiating, that’s in the accept header when you send the request and if you’re using a custom header you’re actually specifying an additional HTTP header that you’re sending out that is not part of a typical request. It’s a custom one so it would be like X my app version.
Rohit B.: Exactly and then what you’re doing, is that hey you can either do it that way or you can say, X my app version for this date. You can say that. Hey, my date is … this is the date I am supporting against and then if the client wants to verify the newer version is working and then they just have to change their version scheme.
Michael C.: Sure. The known good for any particular date. I like that. It’s more meaningful than necessarily version numbers.
Rohit B.: Exactly. The way I put it is that you know, both these models are really good, like custom header or content negotiation but it does add some kind of complexity no matter what you do. Important thing here is you have to version your app.
Michael C.: Of course, it’s going to happen. Otherwise you’re just going to break things and I guess there’s a certain scale of organization that when you’re so big it really doesn’t matter if you break your APIs because I feel like Facebook breaks their API all the time and it’s kind of when you’re a 400 pound gorilla you sleep wherever you want.
I don’t know. I know they are kind of careful about it. My perception as a developer is that, this is broken again? Seriously?
Rohit B.: That’s a bigger problem. Of course, and this is the nail in the ground that hey, the 400 pound gorilla, the 800 pound gorilla, they can change their API and that’s still fine. They can do that but as part of your value proposition. That’s why I was always coming from the perspective of ideal design first, you have an ideal design in place as we discussed before. You want to make sure that how that is built, what are your attributes that you’re supporting that, you know. Verbs. In stead of supporting verb, you support the noun for you application for the rest APIs and points.
The important thing is once you design it, once you have a versioning in place, now you are really ready for the next step which is basically looking at, applying different patterns to what you’re trying to do from the rest API perspective.
Michael C.: Talk us briefly through a couple patterns that we really need to be looking at.
Rohit B.: There are a lot of patterns. There are some best practices for the rest APIs which we should always try to incorporate in our design. The important thing is that you have to look at who’s using it. If we are looking from the performance perspective, you might want to look at e-tags, a caching mechanism so if your data is not changing that often, you want to make sure that it’s always available for you all the time.
Maybe the data is not changing for two minutes so why do you want to leave and get the data from there? Another aspect which you can look at is, is the filtering mechanism. So instead of getting everything from the world, you can clear your own filtering mechanism where you can say, you can create your own language or a query language to get the data from the database where you say where I want to get the data from this date to this date and by the way I want only fly in the morning time frame and in the evening time frame I want to come back.
When you send these out, what’s happening is that the client do not have to filter this data. Those data will be filtered as part of your solution if so and that kind of gives us the low cost of using that data also.
Michael C.: Okay, and we’re getting a little short on time but I do want to talk about one more aspect of this entire thing that I really think cannot be overlooked and that is, the whole testing process. What are your thoughts on that?
Rohit B.: Testing, if you think about testing as a whole, it’s the most important part of API development or micro service development. Wherever we build our microservice, all the API which we are trying to build, we have to make sure that it has a contract and normally what happens that customer has to give their contract to you. And that’s where I was starting from number one. What is my use case looks like? How am I using it?
Michael C.: And this brings it all the way home to …
Rohit B.: All the way home to the number one, number two steps where how they are being used. Based on that the customer is going to give me my contract. This is my contract looks like. You can look at the packed file micro service design pattern where basically what you do is the customer sends … this is my expectation looks like and based on that expectation you write your micro test to satisfy that you are getting still the values from the service.
Otherwise I use is rest issue and using rest issue I want to make sure when we use that particular model it’s performant. Not only performant, important thing with the rest issue is that it does similar to the back file but you are basically building just like a general test model. You have a general test which you are building and it’s got to, on a running server it will just test out your particular application.
That does not stop there. When we do the integration testing, all these JSON unit test you want to build as part of integration suite. When I say suite that means how many layers is it going through. If you think about it, what’s really the problem with our testing approach, right now? We say that okay, I’m just testing the rest API. We now look at it from the end to end perspective. If I think from the end to end perspective, what’s really happening when I’m seeing some data through oracle database or some other database I also need to stream that same data using Kafka as a broker or [Rowlin 00:33:26] queue and sending that data out and it needs to get passed using spot jobs or somewhere collecting the data, filtering the data and then putting it into our central database, some database and retrieving the data out for our fast access.
That’s just one aspect of it so how am I going to do the maintainability of it?
Michael C.: You’ve got to have that process.
Rohit B.: Exactly. People think that oh, I just got an exception sorry I cannot do anything about it. How important it is that exceptions have to tell exactly where the problem took place. What happens is that we just send a generic error message out but with that generic error message can we actually pinpoint to where the problem is? Is it my message broker which is broken or is it through Kafka, there is some layer which has a problem. Those things we have to find out. We have to know where could be the problem coming through.
That takes care of the integration and do an integration test that’s different than just saying that okay, I just added these values and if it’s there in my you know sequel so oracle database I’m all set. Not really. The same value also needs to be there in cash. If it’s not there in cash, then something happened wrong in between like you know, if you are maintaining ready cash for most recently used items you want to make sure that’s highly available for you to use so those patterns you have to apply. Next comes is performance.
Now, performance is one area where we just look at from one aspect of it, okay, my API should perform.
Michael C.: What does that mean? Does that mean response time? Does that mean concurrency? Does that mean general load? There’s so many different …
Rohit B.: Exactly and those are the questions which we need to ask. What’s the concurrency level which you need to support? Not only the concurrency level, what is your, you have to define what is your supportability limit from the performance testing.
Performance is a key part of our API development. When we look at performance, it’s not just looking at from the aspect of hey, how performant my API would sync alone but how much, how best I need to perform under the load. How many concurrent users are there and what’s the response time should be for that users. You also want to build some level of throttling. The problem comes is if you don’t build the throttling as part of your design, then someone can call your application 100,000 orders. I want 100,000 orders from past two years.
Not really a good design if you support that. If you [inaudible 00:36:36] I may have to support that kind of design so we can talk about how to do that but for throttling means that at service limit, what does your service limit looks like? Service limit could be based on number of customers you are asking for and the data range you are asking for.
Michael C.: And I think that’s worth talking about the circuit breaker pattern as well.
Rohit B.: Exactly, so one thing which could happen wrong here, one is the load. What is the load which is there and secondly, if there is something goes wrong, like that can be supported through a different pattern. Circuit breaker is just one of the patterns for the resiliency which we need to build in our system for doing what we need to do.
What I was trying to say for the performance perspective is that you want to make sure that when you’re looking at a performance you create your own service limit. That means just to finish that loop and then I’ll come to the circuit breaker also on this one. What’s really happening is that you want to make sure that if I have 10 users, 10 customers who are calling me they can ask for two years of data. That’s fine.
But if they’re 2000, if you’re asking for 100,000 customers data you can only ask for a month of data, so that’s the kind of limit which I’m saying, what’s the volume of data which is getting into changed between the systems so that’s also very very important in this case.
Michael C.: And that’s actually why it’s so important that you’re going through your steps two and three. You’re actually doing some level of capacity planning as part of the finding these use cases and the scope of the project itself because I think so many developers and even some architects that I talk to, they love to talk about scalability and they’ve never talked about capacity planning.
Rohit B.: Yeah, capacity is the key and if somebody comes and say, “oh, I really need to support 100,000 of them likes,” yeah, you can do that. Do that as part of integration hub support, when the integration, from the integration hub you’re supporting, maybe you’re using meal soft or using some other tool which you’re using for that camel integration, other ones, there you’re chunking the data, you’re chunking the data with the service limit calls and then you’re basically combining the data and sending it to the user so there are many ways of doing that aspect of it if somebody’s really wants to do that the batch processing behind the scene it’s still performant. It will not break and with the service limits, another advantage is that now with the service limits you can ask the same data which you are asking for. Lets say you’re asking for two years of data.
Maybe you want to ask one month data each but you are asking in panel. So now I can paralyze my data. Now what’s really happening when I paralyze my data? It will be calling my rest APIs in panel. Wow. I get the response really fast because now it’s within the service limit. I’m able to perform with that kind of load but still be performant because it’s stateless. I can combine that results on the other side and still send a value to the user.
Michael C.: And I want to circle back just very briefly to the circuit breaker pattern just to kind of continue that thought and then lets wrap up and talk a little bit more about your book because it sounds like there’s a lot of really great information in it and so just going back to the circuit breaker pattern very briefly and some of the similar patterns.
Rohit B.: Oh, yeah, so what’s really happening … now these are all cloud patterns. It’s not just like they all started with Netflix OSS when they came along. Netflix had the same problem. You know, we all facing the similar kind of problem that Netflix faced in 2008, 2009 time frame when they started working on their APIs. When you used to watch the movies at that time, it used to break in between and then they found out that the problem was the APIs they were calling they were calling the back end, nine times to get the data. Which is kind of a chatty application.
Lot of our applications have, again become chatty because of the HTML five implementation. You have implemented in a way that you’re just calling it back and forth to the server to get the values instead of that, you get all the information and be able to support that through with this one.
Michael C.: So the application’s becoming less chatty or we should strive to do that. I think a big part of that chatty application architecture started to happen when we were doing more of these back and forth calls but also I think it really started when doing a post back. We didn’t have to do post backs for everything that we did a lot of these small little transactions back and forth all the time.
Rohit B.: Exactly, and the problem with that. I don’t have any problem with that. If you have a load which you’re supporting two concrete users or five concrete users, if you support 50 or a 100 concrete users, the application will just collapse.
I have seen first hand like you know on some of my other friend’s applications when I was looking through them, and the application just collapsed because you’re calling so many calls are being made to the back end just to get small information. How bout you do the whole processing and then send that thing out? And that actually saves you a lot of your time, getting your application concretely. It should be competent. All the rest APIs calls must be stateless. That’s the key part here and that’s the only way you can get the resiliency which we are really looking for.
What it means, that hey, if my rest service goes down, it doesn’t matter, you can use the circuit breaker pattern and be able to support through infrastructure. It will call using the service locator. It will get another instance of that same service and be able to satisfy the request without any problem so those are the things that can really help us build in information what we are really looking for and important thing from the pattern perspective is having ability. Like when we say we are highly available it means that you’re not just having one server, one node to call yourself as part of the resiliency.
You have three or four nodes which have the same data. That’s exactly the same thing which Netflix does. When I’m watching a movie, they use chaos gorilla. Behind the scene, they stop the servers where the movie’s coming from. It switches to another Cassandra node and still the movie is being watched without us knowing something went wrong behind the scene. So that’s where the testing aspect also comes in that you have to put your own chaos gorilla as some seeming army kind of thing, which does bad things to your network. Kind of protecting yourself because bad things are going to happen, like it’s inevitable. As tree went down, it’s like it never went down. No, it went down.
You have to prepare for what’s going to happen. How are you going to make that thing more resilient to your application?
Michael C.: And you want to do that under controlled circumstances. And not situations where you’re not necessarily have to panic. You know, it’s like a military drill. You have to go through these things.
Rohit B.: You have to go through these things and not only that you have to make sure, if you lose your data, how are you going to get the data back? Oh, I’m never going to lose my data. It will never happen. Maybe you’re not losing the data but the vendor you’re working with, when you’re sending the information out to them, they lose the data. What are you going to do in that case?
Michael C.: It goes back to that saying that I think we don’t say enough. All the cloud really is, is just somebody else’s computer.
Rohit B.: Exactly, so if you lose the data that’s another design pattern which is there. You have to be software compliant. You have to make sure, oh I lost my data. Lets take a scenario here where you have a data center which is in Chicago, another data center in Philadelphia and for some reason, the Chicago data center blows away. Why it blows away, because of the snow storm. It just went away. Just boom. It lost the data. Now you have to bring back the data center in a matter of the requirement is, in a matter of four hours.
How you going to do that? You have to find out, I lost the data.
Michael C.: Exactly, and you cannot be doing your disaster recovery after disaster. You need to plan ahead for these things.
Rohit B.: Exactly, and that’s where the failure point is. That’s another failure point, so what are you going to do? You want to find out what delta changes have taken place within your system in transaction so any other system wants it, they can get from you. Normally what happens, what are the kind of rest APIs which we bill. We just say okay, “give me the whole data range and I will get all the data to you.” Not really. What really changed? In the last, you know, few hours. I only want to sync up that data because the data loss scenario you have to take care into account for this case.
Michael C.: Really great stuff and I just wanted to thank you for all your time and everything you’ve shared here. Tell us just a little bit about your book.
Rohit B.: The book is coming along. The important thing is all pain points which I saw when we started working on, going from monolithic app to building a cloud native app, important thing is not to just think through and whatever your app is, you’re working on top of it and a lot of people do that. They have their building, working, making more things on top of it. What we really need to do is we need to define the problem. What is the problem we are solving. Then we need to make sure, define the use cases. What are the use cases which is going to give you the bang for your buck, do you want more availability? Do you want setup only? Those kind of use cases and based on that, you come up with either a design pattern which really works for you based on availability partition tolerant and consistency.
Based on those aspect then you come up with your ideal design and that design will not just a design which you’re building but you’re building a design based on the industry standards. Looking at schema.org and a.org. All the micro formats so that you build a standard JSON object. Not just for yourself that particular JSON object. Then we talked about basically looking at from the API perspective that you create a façade layer which provides you the support where you take care of your gateway. You publish that and because you’re publishing that API gateway, integration hubs, everyone else can use that same model. Come up with a common design patterns for error handling, logging, security aspect of it.
We looked at that at the end and later on, the key part which I always say here is find the failure points. Those are the golden nuggets which you want to find out and once you do that, that will drive your strategy to improve your API. There again you come back to number one, define the problem and solve that problem.
Michael C.: Absolutely, so this is designing cloud native restful microservice APIs?
Rohit B.: Yeah.
Michael C.: And be sure to watch for that coming out and I know we’ll definitely be posting a review on the No Fluff, just stuff blog and you’ll probably see some other places where it’s popping up and talking about it.
Rohit B.: April, one my articles is coming in the No Fluff.
Michael C.: Oh, yeah definitely check out Rohit’s article in the No Fluff, Just Stuff magazine as well. Rohit it’s been a real pleasure. Thank you so much for joining us and for all your time on the podcast here and we look forward to seeing you at future No Fluff stops.
Rohit B.: Yeah, nice seeing you.
Michael C.: Now if you’re an engineer working in the JBM space or if you’re an architect or you’re an aspiring architect or you’re really interested and really focused in the rich web space and in modern web development. The java script APIs, java script frameworks then you really need to check out our whole suite of offerings on the No Fluff Just Stuff tour. We travel the country on a road show bringing the best technologists to you. We’ve got tour dates all over the country this year in 2017 on our website No Fluff Just Stuff.com. We also have a few destination shows and you really want to check these out if you are an architect, if what Rohit was talking about today really speaks to do, we have a conference for you.
It’s Rconf taking place in December in Clearwater, Florida. Check that out at rconf.com. If you’re a web developer, you’re interested in that space, we have the rich web experience also taking place in Clearwater Florida and that’s richwebexperience.com. The richwebexperience.com.
And finally, we have the angular summit which is focused exclusively on reactive client side programming, modern java script, angular summit, again that’s taking place here in May in Chicago Illinois and we have our flagship event. If you really want the ultimate conference experience, go to uberconf.com. Uberconf is the biggest, the greatest conference. This is our flagship event taking place in Denver Colorado in July. We have 11 concurrent tracks. We have 160 plus sessions. We have 11 full day workshops. We’ve got a bunch of half day workshops. It is the ultimate conference experience. If you want to go to a conference that will blow your mind, definitely check out uberconf.com.
My name is Michael Carducci your host and I look forward to seeing you on the road.