 Hey guys, my name is Jose Montoya. Welcome to this talk named Tavros and Kuma, Essential Software Concerns at the Platform Level. A little bit about myself. I work for a company called Mountain State Software Solutions or MS3 for short. We specialize in enterprise integration software, cloud migration strategies, and API enablement. So I've been doing this for about five years now and for the last six months to a year I've been the principal product manager for Tavros. Tavros is a enterprise integration platform for MS3. Today I'll be taking you guys a little journey between what Tavros is and how we use Kuma to address some of these essential software concerns at the platform level. So we'll get right into it. So the first thing that we should do is talk about this essence of software. So the concept comes from a book called The Mythical Man-Month. You might be familiar with it. It's sort of a classic in software engineering. In this book, Frederick Brooks has basically a collection of essays about software engineering in general. In particular, there is one called No Silver Bullets, The Essence and Accident in Software Engineering, where he basically describes what he thinks the essence of software engineering is. Here's what he says. The hard part of building software is this specification, the sign and testing of this conceptual construct, not the labor of representing it. Basically what Brooks is saying is that the hard part is really understanding what it is that we want to build and kind of creating our mental, this conceptual construct, right, designing it even as a conceptual construct. The part about representing it in the software in a programming language is kind of accidental complexity, right? The hard part is really that conceptual construct understanding and designing it in our minds. He goes on to talk about how he doesn't envision any individual breakthrough in software engineering that is going to really revolutionize the productivity levels that we have when we create software. He talks about things like higher level programming languages or object orientation or even artificial intelligence as things that he doesn't think are going to be monumental in their effect on software engineering. He does have a few things that he considers to be worthwhile attacks on the essence of engineering to provide this kind of boost the productivity. He lists four. I have grouped them here in two groups of two because I think these groups kind of go together. I'll go through them now. First is the requirements, requirements, refining and rapid prototyping. Basically here he talks about iteratively refining your requirements gathering, right? So there's no way that we can get our requirements precisely and accurately all up front. So we might as well just prototype and learn as we go. Just keep refining our requirements and prototyping as we go. I think in the same vein he talks about incremental development where he basically says that instead of trying to deliver all of the features of a software product kind of all at once with the final nail, just kind of do it incrementally, right? So start from a kind of very bare piece, maybe even useless, but you know, standalone and functional and start adding features incrementally, right? So the analogy is to grow software instead of building it as a building, just grow it as a living thing. So I think these two attacks kind of go hand in hand and to me I grouped them together because this for me is just inspect and adapt, right? And so some of the words might have seemed familiar to you guys when we think about agile development for example or continuous delivery. The idea is that we want to go at it piece by piece incrementally not all at once. So agile and continuous delivery I think kind of fit that same idea of, you know, incremental development prototyping and requirements refining. Microservices and containerization I have here because as we make these units of functions smaller, it makes it easier for us to prototype. It makes it easier for us to try different languages, different designs, different framework, et cetera. And observability I have here because it is imperative for us to have good observability into our systems in order for us to really inspect meaningfully and have the ability to make educated decisions on that inspection in order to adapt. The other two attacks that Brooks talks about in his book is buy versus build, which I think is the main one. He's basically saying the most productive time, you know, trying to deliver software is when we don't spend that time at all. So basically, you know, you buy an off-the-shelf product that meets all and not most of your requirements. And the other one is great designers where he basically just says, hey, at the end of the day, software is sort of a creative process. It's an artistic process. So some people are just going to be better at it than others. Specifically, you know, more experienced developers are always just going to be better than those non-experienced. So he talks about, you know, spending time and resources on people and get them to be these great designers. But at the end of the day, again, you just have to have good people, good designers. And so these two, I kind of take me into the main driven design, right? So the main driven design by Eric Evans has this concept of distillation, which is basically to say in your software components, in your IT landscape, in your industry, you got to identify what he calls core domains versus generic subdomains. So your core domains are going to be those things that are essential to your business that drive business value for your company. And the generic subdomain ones are going to be just supporting roles that are still essential, but are not the principal drivers of value. They're not the things that are going to differentiate you versus another company in the same industry. So for example, if you think about banking, a fancy CRM is not going to be my core domain. It's not going to differentiate me from another bank. You know, the latest and greatest identity management system is not going to be my core domain. Banking services is going to be my core domain, how fast a customer can open a checking account from their phone. Internally, how fast or how easy internal developers can gather information from six or seven different backing systems that have different types of accounts, how easy they can consume, compose and maybe filter that data to provide mobile phone user interface, maybe even an Alexa conversation or a website, etc. So these are things that do drive the business value that we can offer as a bank that differentiates as a bank. So these will be our core domain. So the idea is that through distillation through this process of identifying core from generic subdomains, we can strategically decide when to buy versus bill. The other point that Eric Evans makes is that because generic subdomains are generic across industries, they've been studied more. They're kind of more tractable. They're not domain specific. They're easy to understand and attack. So they sometimes attract your more skilled developers. So what ends up happening is your your great designers end up working on the things that bring you the least amount of value. So again, the idea is spend some time identifying what you should build versus versus what you should buy and act on those, you know, on what you've identified. If we take it one step further, we can identify even more things that ought to be considered in this process, which I call generic cross cutting concerns. These are things that apply regardless of whether there is a core domain or generic subdomain, things like security, logging, tracing, any of these cross functional cross cutting concerns that apply. And you need to think about it because even though they still play a supporting role, it's still essential. No one's going to use your system if it's not secure. So yeah, we need to keep this in mind and try to bring this into this strategic buy versus build. But we'll start with the generic subdomain. So let's say once we've identified, you know, I'm a bank, I don't need to build a CRM. And we identify all these products and we say we're just going to buy them. We're going liberate our developers, our great designers to work on our core domains. And not on the generic subdomains that are only, you know, supporting, they're the supporting cast. Great. Great first step. What happens though is that now that you have off the shelf products, you bring in some challenges around integration. Now the surface here is going to be smaller than your core domain because integration is mostly going to be about translation and orchestration. But it's still a place where you can drive value value from right. So if, if, if you're a bank again, and you bought a system for mortgage, mortgage accounts, a system for credit card, credit card accounts. If you develop a integration component that allows you to view all of those accounts uniformly from independently developed components, that's a differentiating factor, right? It makes it easier for your customers to access their data. It makes it easier for you to developers, I'm sorry, to develop differ, different user interface experiences for you, for your customers. So it does become a point where you can drive differentiating factors in your industry. Yet we still have to worry again about these generic cross cutting concerns. We have to secure this integration components. We have to make sure their performance that they have blogging and observability, et cetera. So that becomes our next step. How do we buy versus build these generic cross cutting concerns that are not really what gives us value as a bank or any other industry, right? How do we address these so that we can focus even more on the core domain or the integration domain to drive value? So there's two ways of solving this. One is through application or language specific library. So we can say, okay, you know what? There's a spring boot library or a dot net core library that solves security and it solves tracing. So we're going to mandate that all our applications are going to be developed in this one language and we're going to use this library. You've solved it, but you've kind of gone against the idea of containerization and rapid prototyping because, and with microservices because the idea is that you should be able to experiment easily to say, maybe this one particular component would be best implemented in this other language or this other framework. And you can do that now if you've chosen to solve these generic cross cutting concerns through a library. So the other way to solve it is through service mesh. And for that, we've chosen to use kuma. So what this does is it solves those concerns just the same, but in a way that is independent of the language implementation framework, anything that the actual workloads are implemented in. And so this is the decision that we made at Tavros and we'll get into that now. So, you know, given the rise that we've seen obviously because we're in this industry of enterprise integration, we've seen a clear demand and a continuing to grow demand for an integration platform that solves a lot of these, you know, kind of generic concerns for them because as more off the shelf products become available and as, you know, we kind of digitalize ourselves as a society more and more, these companies are figuring that, hey, maybe I really should only spend my time on what makes me, you know, better than my competitors instead of trying to solve logging and tracing and security over and over again. Because that's what we find as a consulting company is that we end up so solving observability in 10 different ways and 10 different clients because they try to do it on their own way. Not to say that that's bad, but that's not, those are not the main, you know, the principal drivers of value for this company. So that's not where they should be spending their time. So we committed to Tavros, which is our enterprise integration platform, writing and orchestration and data transformation are at the heart of it. But we also wanted to make containerization important because we didn't want to be that platform that says, hey, only if here's our engine and our data transformation framework can you deploy to our platform. If you're not using that, then you can use it. You have to use a different platform for your other workloads. And we know some platforms that are like that and we find them to be, you know, pretty limiting. So what we want to do is make sure that whatever choices we make to address some of these concerns for our customers that they were being addressed in a way that was independent of the language and then the framework. And so that's what we achieved through service mesh and through Kuma, like I explained to you before. And then we just chose open source components to address other of these concerns, right? So like observability, security and continuous delivery. This is a pretty high level overview of what Tavros is. So on the top right, for example, we have our observability components on the top on the bottom right, we have some of the other ones like eClick for security, SonarCube for static code analysis, things like that on the left. We have Jenkins and Flux, for example, driven by Git. So this kind of GitOps and continues delivery. This provides GitOps and continues delivery for our platform and for our workloads. But in the middle here is what we have is where we have the application workloads that are fronted by Kong as our API manager and load balancer and Kuma as our service mesh to provide a lot of these generic cross-cutting concerns that we talked about in a way that is independent of the implementation language or framework. So what that ends up meaning for us is that we have this generic workload that there's an application in whatever language and then there's Kuma. In this particular diagram, we're highlighting observability, so we're saying, hey, regardless of how you implement your application, Kuma is going to do observability for you. If your application happens to be aware of distributed tracing, then you can augment what Kuma offers with application-specific tracing. But if it doesn't, no worries, a generic workload will still participate in your distributed tracing because of Kuma. If you have an integration workload and you go with our framework, then you'll get some of this application augmented data. We've chosen camel and data sonnet for engine and our data transformation and open tracing for our distributed tracing in process framework. This will automatically be set up in a Tavros integration application, and so Kuma is going to do what it does with distributed tracing regardless of the type of app. But then, because this is specific to Tavros, you'll get some application-level tracing information like the step and the route in your integration flows, and then you can do custom application-specific context diagnostic tags and things like that. But the whole point of all of this, again, is to address these essential but supporting concerns of software so that the great designers, so that the application developers can focus only on the application-level concerns. So they can actually get to the part that drives value in their business. So we can move that responsibility from the application developers to the platform. So talking about Kuma specifically, what we do in Tavros is we have, you know, designated namespaced environments for workloads. Anytime there's a deployment in one of these namespaces, you'll automatically get some policies applied to your application again so that the application developer transparently gets all this value without really thinking about how it's installed and configured, etc. So what happens is as soon as an application is installed is deployed into one of these environments, they'll automatically get a tracing policy that Kuma is going to start adding tracing information for every incoming request and every outgoing request. If this application happens to be one of the integration workload from our framework, then you'll get that optional application-level data. But again, if it's not, no worries, you'll still have the benefits of getting these cross-cutting concerns addressed because of Kuma working outside of your application language. And so in our demo, what we have here is, for example, this is our logical structure, right? So we have Kong being the load balancer, the ingress basically. Then you have CRM Mobile and CRM Conductor implemented in a language different than our integration framework. It could be .NET, could be anything really. So you can imagine CRM Mobile doing some mobile-specific transformations and CRM Conductor is basically an orchestrator that goes into two integration-specific applications. One is CRM Salesforce that goes to talk to Salesforce and the other one is the database that talks to a database. The idea is that you have some customer data in both of these sources and you want to compose them for displaying them in a mobile application. And so what ends up happening once Kuma is involved in all this tracing information starts being gathered and reported is you end up with a graph like this in a system like Yeager, which is the distributed tracing system that we install and configure automatically for you in Tavros. So you can see it's almost a one-to-one representation of our logical understanding. So you have Khan, CRM Mobile, Conductor and then the two one for each implementation with their integration-specific applications. And so what this does, and this is just a general point on observability, is because we've adopted microservices as an architectural style across basically the whole industry, you start needing these sorts of tools. You start needing graphs and charts in order to make sense out of dozens and hundreds of services. You need to start being able to have analysis, root cause analysis, latency analysis, figuring out what sort of stuck to what other surface, why this particular transaction failed, where did it fail, things of that nature. So you get this for free in Tavros because of Kuma's tracing policy and its ability to work regardless of the implementation. This is another example that we have here. So if you see here in the middle, we have CRM Database and this is again because the CRM Database workload was in our integration-specific framework, we get application level tracing data. So here we have data around a set header operation or a processing operation. Here we have a logger, we have a delay, things like that. So the idea is that when you have an application that can augment what Kuma can do, great, but if not, we still have conductor here, we still have mobile, we still understand what is actually going through our integration stack, through our IT landscape. So that is the value that we needed to achieve for our customers and that we wouldn't have been able to without something like Kuma. When we tie this into your log aggregation system, like we've done between Yeager and Elastic, you can do a lot of neat things like correlating your traces with your logs, doing, like we said, all of these root cost analysis, latency analysis, you can start doing trend forecasts and things of that nature. You can start seeing your worst offenders in sorts of errors and in one single pane on glass, navigate from a high level dashboard of who's being having more errors in the last week to a specific error that has been showing up in a certain percentage of your calls. So that's observability. The second one that I wanted to highlight, let me do a quick time check here. Over time already. So the other one that I wanted to highlight is mutual TLS. And this is another one that we do by default in Tavros, which is basically any deployment that any workload that is deployed into one of the environments that we manage through mesh through Kuma service mesh will automatically also be enrolled in mutual TLS. Kong sits in the middle because it needs to take in requests externally, obviously, but anything from that point on needs to be in this trusted environment. It needs to have a certificate provided by Kuma. So we transparently provide all this information. Your developers no longer have to worry about certificate authority, certificate signing requests, rotating certificates, all this stuff that is really, really hard to do really gets addressed transparently by Tavros through Kuma for the developer again, to only have to worry about that application level logic about really driving business value for that company. They don't have to worry about the stuff. These are those generic things that we wanted to address. And we're able to, we're able to because of Kuma. And this allows us to provide things like zero trust security. And extending that through open policy agent, we can say, hey, not only are we providing the security, but we're doing it in a way that is so simple to understand and configure through declarative configurations that say, you know, all these services must be in a mesh and only A and B can talk to C. And further than that, we need to make sure that a particular all scope is available when this other one calls that other one. And so it becomes a place for you to govern in a single easy to understand declarative way exactly what should be going on internally in order to provide an easy to consume and manage zero trust security. So like I said, I'm basically out of time. So I'm running through this last slide. That kind of does it all for me. I think I'll be taking questions now. These are some links that I'm putting out for you guys in case you're interested in Tavros and the work we're doing. Thank you so much for your time.