Screaming in the Cloud - Evolving Alongside Cloud Technology with Jason McKay

Episode Date: March 9, 2023

Jason McKay, Chief Technology Officer at Logicworks, joins Corey on Screaming in the Cloud to discuss how the cloud landscape has changed and what changes are picking up steam. Jason highlights the benefit of working in a consulting role, which provides a constant flow of interesting problems to solve. Corey and Jason also explore why cloud was positioned well for the current economic changes, and how Kubernetes is slowly but surely becoming more standardized. Jason also reveals some of his predictions for the future of cloud-based development. About JasonJason is responsible for leading Logicworks’ technical strategy including its software and DevOps product roadmap. In this capacity, he works directly with Logicworks’ senior engineers and developers, technology vendors and partners, and R&D team to ensure that Logicworks service offerings meet and exceed the performance, compliance, automation, and security requirements of our clients. Prior to joining Logicworks in 2005, Jason worked in technology in the Unix support trenches at Panix (Public Access Networks). Jason graduated Bard College with a Bachelor of Arts and holds several AWS and Azure Professional certifications.Links Referenced:Logicworks: https://www.logicworks.com/LinkedIn: https://www.linkedin.com/in/jasonhmckay/

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is brought to us in part by our friends at MinIO. With more than 1.1 billion Docker pulls, most of which were not due to an unfortunate loop mistake like the kind I'm like to make,

and more than 37,000 GitHub stars, which are admittedly harder to get wrong, MinIO has become the industry standard alternative to S3. It runs everywhere, public clouds, private clouds, Kubernetes distributions, bare metal, raspberries, pi, co-locations, even in AWS local zones. The reason people like it comes down to its simplicity, scalability, enterprise features, and best-in-class throughput. Software-defined, capable of running on almost any hardware you can imagine, and some you probably can't, MinIO can handle everything you can throw at it. And AWS has imagined a lot of things, from data lakes to databases. Don't take their word for it, though. Check it out at www.min.io and see for yourself. That's www.min.io. Welcome to Screaming in the Cloud. I'm Corey Quinn.

Back again for another promoted guest episode is Jason McKay, the CTO at LogicWorks. Jason, thanks for coming back. It's been, what, about three years now? It has been. Thank you for having me, Corey. Really appreciate it. Yeah, it's interesting seeing how companies have evolved. And in many cases, I wind up talking to folks about what they're doing and, oh, what does your company do? And then you talk to them a year or two later and, oh no, we're deep into NFTs. And then you ask them six months later, NFT who? And you wind up with these constant pivots that seem to be so frequent that you could strap a magnet to some of these places and generate electricity just by wrapping it with wire. But Logicworks has been around for, what, over two decades at this point? Well over two decades at this point,

under a different brand in the early days. So the entity has been around that long, but what we do has definitely evolved over time and continues to do so. If you'd asked me 20 years ago whether I envisioned myself at a company for 18 plus years, I would have laughed at the concept.

But here I am 18 years later, but having worked on many different paradigms of providing services for our customers. So that's kind of the opportunity that we have is to keep evolving as the technology world evolves. So these days, I tend to mentally bucket you folks into managed services provider. In other words, using cloud is not only annoying, finicky, and let's be honest, more than a little challenging some days. It's also not the core competency that a lot of companies are striving to develop internally. It is the means

to what they do, not actually what they do. So is that directionally accurate as far as what it is you folks are up to? Absolutely directionally accurate. So, you know, folks have line of business applications or whatever it is that they're actually delivering that offers value to their enterprise. And they all recognize at this point, thankfully, that the cloud is the future of where applications will run and be delivered from. But they don't know how to connect those dots. They know they want to get there, but they don't know how to do that optimally. That's one track. And then there are other tracks where folks have just gone guns blazing straight into the cloud. They've set up application environments, they've started

operating. And then, you know, they wake up six months later with huge bills and inefficient deployments going, okay, this was not what I thought, right? So this is not what the glossy brochure promised. What happened? Yeah, this doesn't just run itself, right? And that's another problem that we get to step in and solve, which we enjoy. As a general rule, I tend to take a fairly dim view in the aggregate of managed services providers. And I want to be clear that the reason that I take that perspective is that an awful lot of them are, to be direct, crap. You don't fall into that bucket. Otherwise, we would not be having this conversation, to be very clear. We've had some mutual customers in years past. We have had conversations with folks who have worked with

you and have had glowing things to say. And I think the reason that a lot of managed services providers get a bad rap, deservedly so, is because what they fundamentally do is they are offering one size fits you. Whatever you happen to be, oh, you're not a Kubernetes shop. Well, you are now, and you're going to run things the way that we run things, or you're not going to be our customer. And they back away rather heavily from the idea of adding value in the old model of value-added resellers. And now they're just trying to resell cloud at a slight markup or do some discounting magic. But all they're really doing is getting in the way of you having conversations with your cloud provider directly. So they extract

money, but don't add a lot of value in return. That has never been LogicWorks' reputation, but I have to imagine you encounter that perception an awful lot when you describe what you do to folks. We can. We certainly can. It's been one of the historical challenges. When people think about the cloud, they think about the ability to automate, to deploy quickly, to fail fast, to recognize something isn't working, quickly rectify it, and all of that. And all of that's kind of anathema to this concept of a managed service provider who's obfuscating all the infrastructure from you and basically locking you out of your systems or making you conform to whatever their model is optimized for, which is likely themselves and their scalability rather than you and your application set. So we've always approached this from a different angle is that you know we're we're going to be flexible with with what our customers want to do what services they want to deploy and we're going to be in the position to add value and expertise on whatever that happens to be within reason

obviously there are some esoteric service choices that folks can make where we don't try to pretend we're ever going to add value but that level of flexibility we think is key and it's what drives retention right so we don't measure we obviously measure ourselves on sales and bookings and all But that level of flexibility we think is key and it's what drives retention, right? So we don't measure, we obviously measure ourselves on sales and bookings and all of that, but the true measure is a customer retention over time, right? Oh yeah, you can take money from people once. It's not that hard to wind up making a sale if you just lie through your teeth. The problem, of course, is that contracts come up for renewal and you kind of want to

have a positive reputation. You eventually run out of people to swindle on some level. That's absolutely true. And, you know, frankly, without casting too much disparagement on our competitors, a lot of our competitors out there are just really kind of rebranded professional services shops or just doing engagement based work. Right. They don't have that requirement to deliver satisfaction to the point where at the end of a three-year term, somebody is going to be perfectly willing to re-up and do that again. So that's that obligation we carry with us and we take very seriously. So it leads to a completely different approach to the customer. across our customer base and develop solutions that will solve 90% of those issues without impacting our customers from operations or value perspective. But that's our job to do that without

making the customer conform unnecessarily. I mostly tend to encounter a lot of these folks when our clients talk to us about, well, a managed service provider is offered to come in and what they're going to do is effectively lump all of their clients together to get bigger discounts, and then share the discounts with those clients. Do you think that's a good idea? And my response has always been, let's be clear, this is an old business model that's existed for a while, and if I thought it added value in any way, shape, or form, I would have done it myself years ago. It's effectively just trying to do discounting around the margins, but it adds no real value beyond a straight percentage discount and winds up complicating things massively. I think there are better ways

to get to that outcome without effectively having to be subject to the whims of a third party that doesn't really care about you and what you're doing. That is certainly not the entire market, but it's what I tend to see in my particular niche. Now, I've seen plenty of it, and I agree that that alone is not a sufficient trade-off of value to limitation in my mind. A certain degree of cost savings for your customers, if you can get that through scale, obviously, why wouldn't you provide some of that to your customers? But I would argue that that can't be the only value prop in this scenario. So just take, for example, cost optimization. We don't view that as just giving you a 5% discount because of our scale in purchasing public cloud resources and passing a little bit of that through. Cost optimization for us is really, we have a FinOps

team that will meet with our customers on a regular basis, do an analysis using tools that are out there to look at their costs, do right-sizing of their resources in the public cloud, identify new services that they could leverage that would solve their application problem but reduce their cost. It's a much more active engagement than just passing on 4% to 5% of the points that you're getting from a public cloud provider. What we do with the Duckbill group, all that we do on the consulting side of our business is we fix the horrifying AWS bill. We fundamentally believe that cost and architecture and cloud are one and the same. So it's not just, oh, go ahead and buy this reservation or, hey, turn off all these things that look idle, never mind the fact that it's the backup site. It's, what are you trying to solve? What are your constraints? How do we work with that? And it becomes a dialogue. It's a complex engagement. It's not something that we can just slap a tool around. Otherwise, again, we might have built one by now over the past six years of tilting at that windmill.

My department in particular within Logicworks is, that's one of our primary missions, is identifying those things that, you know what, this could be a tool. Let's go ahead and automate that component. We have done a lot of internal tool development here for that reason, but it feels on some level like it's, you wind up building precision tools for very specific use cases designed for professionals. And it's one of those ideas of, oh, I'm just going to go around to the local elementary school and start passing out chainsaws. This can end very badly if without the proper context and bounding around a lot of this. The VCs love to go after models.

How do you scale this to the entire world and conquer it all? Maybe I'm just old, but I remember a time where that was not the mandate of every business. Yeah, fair enough. There's also that whole concept of handing out the chainsaws at the elementary school that's very apt because the tooling that you're building to automate workloads at scale in the public cloud has the ability natively to break a lot of things at scale in the public cloud, right? So we have to examine very carefully which things are kind of controlled by expert operators behind the scenes and which things we can expose for self-service to a customer and do that in a safe way. So that's a big part of the, you know, analysis and product development process that we have as well.

One of the challenges that I suspect your team would have would be, if I reached out to get you folks to manage a lot of the stuff that I'm running in the cloud, would be, how do we get off the phone as fast as possible? Because my architecture is legitimately nuts. There's no way around that. I use Route 53 as a database in some cases, for God's sake. I am so far beyond the pale that there is no, forget managed services providers, there is no engineer on the planet that wants to inherit this kind of nonsense. It's like it is for a variety of reasons, some good, some bad, but I'm a very extreme example. Whereas a number of managed service

providers love to go down the direction of all of our customers will run exactly the same things, exactly the same hardware, exactly the same architecture, very cookie cutter. Somewhere between those two extremes is a balance. How do you folks find and strike that balance? I wish we could say that we were just geniuses at it, but mostly it just comes from experience, right? And it's a moving target, by the way. So we devise a solution. That doesn't mean that that's going to be the appropriate solution a year from now, three years from now, right? But if we're looking at things like the enforcement of intrusion detection tooling across an environment that has a compliance framework or something like that, we all know that you can go in and set that up in

day one, day 180, it's going to look a little bit differently and nobody's going in and checking that everything has coverage across the board. So we'll take that as, you know, this is a universal problem where service placement, enforcement, and visibility is something that's common to, you know, a lot of different things. Intrusion detection, anti-malware, some of the cost optimization agent-based services, all sorts of things like that. So we built tooling that enforces the presence of those services. And if it's not there, automatically remediates and sends an alert that something happened, right? And we built visibility dashboards so that our team can look at a client and say, these are the services that customer has, everything's green, let me move on, right? But if I've got, you know, a red spot in there, I'm going

to have to go deal with something. So that's the kind of thing where we're going to enforce a very kind of narrow desired state that is not going to step all over the architecture that our customer has chosen, but it's going to enforce the presence of a service that they've also deemed necessary to be to have coverage in that environment. And that will change over time, obviously, too. So I'll give you an example of backups in AWS, right? We had... Oh, dear. In the old days, there was no AWS backup tool back when we started this. So we actually developed our own automated snapshot with a bunch of features like copying snapshots from one region to another,

copying snapshots to a different account to prevent the whole code spaces debacle kind of thing, and privileged domain, the automatic rolling up of the snapshots into AMIs so we could have faster restore time. And it was a pretty decent tool across the board, but obviously AWS backups came out and they have the ability to do things that our tool did not like backup, some of the file system-based services, some of the database components.

So we're in the process of sunsetting ours and bringing the automated setup and enforcement of AWS backup policies in place over time. So it's a perfect example of how we need to evolve as the cloud landscape changes. The way that I have seen a lot of these things play out is folks like to get stuck somewhere along the way, and then they just push back against any new technology that arises after they find that sweet spot. Anything that they know how to use is great. Anything new is dangerous and reckless. And I think that one of the breakthrough technologies where people might have avoided early on,

I avoided for different reasons, let's be clear, is Kubernetes, where initially it was extraordinarily complicated. The value proposition was unclear. You could make a good faith argument that some of those things are still true, but a majority of companies are running it in some way, shape, or form. What are you seeing with it? I cannot accept that you, oh, we never touch Kubernetes. It just isn't something we find in our customer environments. Kuber who? What? Exactly.

It's all Greek to me. Exactly. Nicely done. Yeah, I mean, Kubernetes is a perfect example. So we were early adopters back in the day of ECS when it was launched. And we used it internally. We saw customers using it. Definitely went down that path. We also recognized the emergence of Kubernetes. Certainly, probably the biggest jump that we saw was on the launch of EKS within AWS and

AKS on Azure. To that end, we're actually in the process right now of formulating a kind of point solution around managing Kubernetes for our customers for that exact reason. But one of the interesting things to note is Kubernetes solves a lot of problems, but it doesn't come without its own set of problems. That's certainly something that we've seen.

We don't really see any of the raw Kubernetes. Nobody's using just base Kubernetes in our experience. Totally could be selection bias, but we don't encounter that. We do see lots of EKS and AKS uptake, which solves a bunch of problems in terms of integration with autoscaling and load balancers and things like that. The touchpoints with the rest of the platform are there, but it doesn't make them all go away. There's still care and feeding that's necessary of that solution. So what we find is customers will come and

they'll be looking for help with a deployment pipeline into your Kubernetes solution. They'll be looking for help with, you know, how do we manage security around it and security controls around it. And then the other one that, you one that I like to say reminds me of the more things change, the more they stay the same, is that we still have to patch and update it, and it's still work that nobody wants to do, and you have to do it, right? EKS and AKS will only support a set at a given time of versions of Kubernetes, and they are not seamless upgrades. There will be dependency and API incompatibility between versions,

and the method of doing those updates so you remain highly available is still something that needs to be managed. So we think there's a lot of opportunity there, particularly around the security and keeping things up-to-date aspects of Kubernetes. One of the problems that we saw early on with the Kubernetes ecosystem, if you could call it that, was, okay, you're going to run Kubernetes. Good for you, probably because, I don't know, someone read it in an in-flight magazine or something,

and that's apparently how strategic decisions get made. But then you had to go down this entire selection process of what you're going to do for observability around it, what you're using for service discovery, how you're going to handle a mishmash of other things. And it felt very much like by the time you made each one of those component decisions as you went down the path, by the end of it, you were running what was effectively a unicorn because the odds are that other companies having made those same decisions became vanishingly small with each additional decision. So everyone was running their own bespoke unicorn with absolutely no similarity or ability to learn from others and what they were seeing in production.

Did that come to pass? Did you see some of that? Or have you found that standardization is more prevalent than the Cloud Native Computing Foundation's landscape diagram would suggest? We think it's getting more standard. Because you're right, the nightmare scenario you described was exactly the state a few years back. And for some folks, it is the state, right? So not only do you have this unicorn, which may be functioning well at that point in time, but you're also completely at the mercy of, let's call him Chuck, the brilliant engineer who set all that up himself and has now been poached away by Google.

And there you are unraveling what he did. So with the advent of EKS and AKS, we get some of the standardization out of the way. We do see a constantly changing landscape of kind of third-party components that you have to stay on top of to avoid that Chuck scenario, at the mercy of Chuck scenario. The selection of that tooling is an area that we think we offer a little bit of value to our customers because of having been burned on some previous selections across. It's the nice thing about this position is you see a solution and it's, again, I also hesitate to call Kubernetes just a thing, right? But we see

Kubernetes deployments of various flavors across different application stacks for different portfolios, for different business verticals and X, Y, and Z. And there's an ability to take advantage of that wide view that lets us sort of make third-party tool selection and things like that a value add to our customers. It doesn't mean that-party tool selection and things like that a value add to our customers. It doesn't mean that we make that selection and we're married to that for life because new things come out. But managing that swap-in of a new system akin to the migration from our backup solution

to AWS backups is just basically what we do. And that's the work that we have to do that customers benefit from. I feel like it's not super well understood in a lot of companies, but being a consultant in a variety of different capacities means that you're inherently seeing something new all the time that you don't often get to see in the same way when you're working on one environment in a more traditional employment role. I used to quip that every year of consulting was three years of experience just because of the variety of things that you wind up getting exposed to. Do you think that that holds weight or do you think that there are nuances that get lost with such pithy statements? Well, there's always the risk of lost nuance, something we

live with every day, but no, I think that's pretty much true across the board. And that, frankly, is why I'm still in the position that I'm in, frankly, after 18 years with Logicworks. And I think that's true of our roster of folks as well. There's a benefit on the talent acquisition and retention side that when you're dealing with different workloads coming through all the time, new challenges, things like that, there's nothing that excites a true engineer mind like interesting problems to solve. And if you're working on one particular application set, those people are at high risk, like the aforementioned Chuck. There's no Chuck, by the way, he's my placeholder. If you're working on one solution over time and you get that

polished up to where you see a reflection in it, at some point you lose interest and you're going to move on. Whereas our folks get to deal with a constant evolving both landscape of technology and public cloud in general, but also new problems coming to them. Sometimes self-inflicted, sometimes just by the nature of technology changing. What are you seeing these days with the past, we'll call it, we're brought up to a year of suddenly the market realizing that spending money forever because it's free is no longer the viable strategy that it seemed to have been for a very long period. Some folks are calling it a recession. Some are calling it a pullback. How do you see that play out in the day to day? Yeah, I mean, we definitely see it. Again, I don't know what label to put on it, but there's a palpable difference. And I now yearn

for the days of free money like everyone else. But the way that plays out specifically in what we've seen is basically a kind of slowdown in decision-making. That's been one aspect of it. Certain other things go into higher demand in this environment so like i was talking about earlier cost optimization or things like that in an environment where you're looking to control costs that's something that goes goes up in demand we definitely see kind of slower commitment to longer term choices so we see an uptick in kind of more engagement-based work which is fine happy to do that as well in general In general, I feel like it's good that the public cloud was established as it is, and it is obviously very well established at this point in a time like this where that's not

going away and the deployment of applications in public cloud is not changing. If people in general are pinching pennies a little bit more, that's fine. We'll roll with that as will the public cloud ecosystem. But it's the power company at this point. So you may turn lights off a little bit more when electricity is more expensive, but you're not stopping to use it. There's been a lot of noise made lately about, oh, repatriation is coming. Companies are pulling out of the cloud and going back into data centers. I haven't seen it. What I have seen is companies being slow or reluctant to move particular workloads to cloud,

or they'll cut back on their plans to completely evacuate the data center as new things come to light. But I very rarely see even individual workloads being pulled back from cloud after the proof of concept stage has been completed. I agree. I agree. People make noises about that all the time. And there's always one outlier company that brags about their cost of deployment because they run their own bare metal in-house in the old methodology, and that's fine. But in general, I think everybody understands that the new normal is here, and that's the way things are going to operate. And you're right, it may slow down some of these very ambitious migration plans,

which frankly probably deserve to be slowed down. If you just look at, you know, a lot of people will set out, I'm going to move my whole data center out above cloud, and yeah, but you've got a giant boat anchor of an Oracle ExaGrid installation that you don't have a solution for in your application stack in the cloud. So putting a little more thought into some of those things is probably going to benefit

everybody. So it's maybe it's not such a bad thing. But at this point, the inevitability of it is pretty established, even if it goes a bit slower during an economic slowdown. What are you seeing around multi-cloud? Either as something that happens accidentally to folks through M&A activity or a team doing shadow IT until it can't be removed anymore versus an intentional strategy that people begin with? How are you seeing it play out in the market? Much more of the two former than the latter. So

definitely M&A, Cloud Sprawl. That's a very real thing. We have that among our own customers, certainly. And a little bit of shadow IT does happen. Not as common maybe as we all thought it would be back in the day. I don't really see anything in terms of a strategic plan to roll out on multiple public clouds of the same application stack. That doesn't happen in our experience. Now, you may choose a particular service from a particular cloud because in your evaluation, it worked out better and you don't have to be married to only one. If one platform has a very good service for something that the other has 80% of, why wouldn't you choose the best breed, right? And obviously,

dealing with just some of the technological limitations there that are not as real as people think, like latency between your public clouds. You've got latency within your public cloud. Sorry. These things are already dissipated. So I think service selection is definitely an area there. And we do that ourselves, frankly, with our own applications. We have components of our applications that run on Azure, components that run on AWS and speak to each other just fine all day. It's always silly to me when I talk to folks who are talking about, oh, we're moving into multiple clouds for durability and reliability reasons. Yeah, and you check back later and ask a few questions, and it's always clear that, nope, we have expanded

the number of single points of failure rather than reduced them. Exactly. It sounds compelling, except it's super hard. Yeah, it is super hard. And you end up, obviously, I think we might have talked about this in the past, but to truly do that, you have to have the least common denominator cloud. Because if you're taking advantage of services that are specific to one cloud, it's not going to translate perfectly to the other. And so it just doesn't really happen in practice.

It's like, it reminds me of the old saying, you know, an engineer starts out with a problem, they decide to solve it with a regex, now they've got two problems at least, right? That whole concept of the simultaneous deployment to multiple clouds, we don't really see. My argument has always been, I've given this advice to a few folks now, of when they were debating, do we expand to a second cloud provider? It's like, sure, that's not a terrible idea given the constraints and challenges you've articulated. But first, just do me a favor, expand Active Active to a second region of whatever cloud provider you're using, because that is a one-to-one match. You have all the same APIs,

in theory, you should be able to do that lickety split and come back and talk to me once that's done and we'll talk about next steps. And you know that I've never yet had someone come back and talk to me because they get stuck with all of the nuance and all of the challenges doing that. Oh, this is an awful lot of work, way more than we thought. Is this where we want to invest our time, energy, and focus? No, it's absolutely true. I've never had somebody come back a week after being given that advice and saying, my active-active site is perfect. My RPO and RTO are both zero. We're good to go. It never happens. So even less advanced availability solutions like pilot light scenarios and things like that, even if you're not looking for that

perfect level of availability, even that is a challenge to do reliably, even with the full catalog of cloud services. And not only that, but doing it is not the same thing as ensuring that it's actually working at all times going forward, i.e. active testing and failover and things like that. I would chuckle if somebody were to say they've nailed that. It's an ongoing challenge. My last question for you before we wind up calling this an episode is, we've been talking about what you've seen over the past evolution and rise of this technology and its continual reformation.

Let's look forward instead. Based upon what you've seen happening, what do you think is going to be down the road as we see other technologies emerge, different patterns start to be considered commonplace, best practices? What are you excited about? What's next? I think we're going to continue the trend toward more abstraction, more PaaS-based serverless deployments for pretty much everything. I think that's going to continue. I do think that some of the observability and insight, whether that, you know, insert buzzword machine learning here, however that develops, I think that's going to mature.

And there's frankly a lot of room for that to mature over time as well. So getting telemetry data out of the clouds on, you know, availability, interaction of services and things like that, I think that's going to improve over time. I think there's opportunity. This is frankly something that we're looking at as a longer arc thing, but there's opportunity to, and I would be shocked if hyperscalers weren't gathering and thinking about this kind of data themselves,

but there's opportunity to do things like service recommendation based on profiles of applications and put a little bit more intelligence into how and where you're running what workloads. And some of the, I think the platforms are probably going to be moving into, and others will be filling in if they aren't, that kind of use of data and thinking and planning about architecture and service placement. I really want to thank you for taking the time to talk through what you're seeing and how customers are experiencing things in the market. If people want to learn more, where's the best place for them to find you? Well, they can find me on LinkedIn. Obviously, go to logicworks.net. We've got an overview of our folks there and our services. And yeah, that's about it. And we will, of course, put links to that in the show notes. Thank you so much for your time.

I appreciate it. All right. Thank you, Corey. Jason McKay, CTO of Logicworks on this promoted episode of Screaming in the Cloud. I'm Corey Quinn, and thank you for listening. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me exactly how wrong I am,

and also mention which crappy managed service provider reseller equivalent you work for. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.