Tag: self-service environments

  • Agile and DevOps for Kiosks

    Agile and DevOps for Kiosks

    Alan Shimel talks with Sam Zietz, the CEO of Grubbrr and Touchsuite, about how software for kiosks can use Agile and DevOps to keep up with a wide range of hardware profiles. The video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Welcome to another segment here on TechStrong TV. I’m really happy to be joined by a good friend of mine today. His name is Sam Zietz. Sam is the founder, CEO of GRUBBRR. You may not know the company but Sam’s going to tell you all about it. Hey, Sam. Welcome to TechStrong TV.

    Sam Zietz: Al, thank you for having me on. Excited to see you again.

    Alan Shimel: Yeah, it’s been – well, with COVID it’s been a long, strange trip. Sam, we’ve never had you on TechStrong TV though. We’ve never really talked about the company. Why don’t we start with that. Give people a little background on GRUBBRR and maybe a little of your own background.

    Sam Zietz: Sure. So GRUBBRR is the leader in self-ordering technology. When you talk about self-ordering technology you think kiosks, mobile ordering, online ordering. And in reality, this was going to naturally occur over the next 5, 15 years. That’s before COVID hit. COVID came about and acted as a huge accelerant. So if you think about how we used to go to a bank and there used to be a teller, that teller got replaced over a 5 to 15-year period of time by online banking and ATMs.

    We used to go to the airport, and in the airport we used to see a ticketing agent. That ticketing agent got replaced by a bank of kiosks or QR codes on your smart phone. Same thing was going to happen in many verticals like restaurants and hospitality and retail, and it’s going to be a combination of kiosk, mobile and online, and that online will be the company’s website or a third party delivery service like an Uber Eats, a Grubhub, or a Postmates. What ended up happening through is COVID, and now all of a sudden nobody wanted to interact with a cashier and cashiers didn’t want to interact with consumers either.

    This was all of a sudden a hazardous position and people didn’t want to shop any longer for that type of work. So that accelerated the move towards self-ordering technology. Then Joe Biden was elected president, and one of this four pillars was this $15.00 an hour minimum wage, and regardless of where you fall out politically, whether you think it will be successful or not, he has, and whether it’s passed or not the minimum wage has increased. And right now we’re in a labor shortage on that end of the market for a combination of factors, many of which is people don’t want to come back and do those types of jobs.

    And as a result, you’re seeing especially in restaurants that they can’t even open their doors many times because they don’t have the employees. So for all of these reasons we’ve accelerated the movement towards self-ordering technology.

    Alan Shimel: Yeah. I mean, Sam, this all falls under what we call digital transformation, right? And digital transformation, as you mentioned, was well underway before COVID, but we’ve probably accelerated four to seven years of digital transformation in the last year, year and a half. And the move towards automation, which is what this is, was again well under way. Quite frankly, when we look at should we automate everything – this is a question for academics – should we automate everything, should we automate only what should be automated or should we not automate everything for the sake of preserving jobs, and whether you believe in a Star Trek future where you get a basic, whatever they call it, wage where they send you money or not, quite frankly, if a machine can do it better they don’t take sick days, they don’t steal, purposely anyway.

    Hopefully not. They’re a better employee in some regards. So if there’s a machine that can do the job better, a futurist or technologist will say by all means the machine should do the job then because that frees up people to do hopefully higher-level work, more valuable work. Now are there some people that can’t do higher level, more valuable work and what do we do with them as a society – that’s probably a discussion for another day. But the fact is that today we have the technology, to quote an old TV show, to do this, and that’s really what you guys are doing there at GRUBBRR.

    Sam Zietz: Yeah. And historically this should’ve occurred years ago. It really was restaurant owners said, “Hey, you know what? We’ve been doing it the same way for the last 20 years,” and because labor was so cheap and because the minimum wage was so low, instead of investing in technology like almost every other industry has they said, “You know what? Let’s just throw cheap labor at it,” and that’s what occurred. COVID has exposed those businesses that had not invested in technology, and quite frankly rewarded those companies that had been proactive.

    They were extremely successful during the pandemic, the ones that had digital, they had an online presence, they had these self-ordering applications already in place. They were hitting record numbers. Everybody else either exposed or permanently shut down as a result. And by the way, these aren’t jobs that anybody wants.

    Even pre pandemic, the average turnover for a cashier in this country was 150 percent annually. I think Panera put out a stat before COVID that they were at 100 percent. And they were bragging that they were at 100 percent. So they were proud of the fact that every one of their employees –

    Alan Shimel: It was only 100 percent.

    Sam Zietz: Yeah. So these aren’t –

    Alan Shimel: There’s no doubt. Look, I think we’re both saying the same thing. This is the way it was going. We just had an accelerant take place. So let’s talk now about GRUBBRR. So you guys are filling that void by developing software solutions that allow for self-ordering. And whether people are ordering online via the internet for like a third-party delivery or in person, it’s still a software-empowered transaction. Like everything else, software is leading the world.

    In your case though, Sam, the challenge is that even with self-ordering it comes in a lot of form factors. It comes in a lot of shapes and sizes. And how do you make a software that is shape and size, form-factor independent? I imagine that’s got to be a challenge.

    Sam Zietz: Yeah. Well, we’ve got talented dev people, so from my perspective it’s easy. They do all the hard stuff.

    Alan Shimel: You didn’t write too many lines of code. I get it. But the challenge is there.

    Sam Zietz: We’re agnostic on the hardware side, so we work with all of the leading kiosk manufacturers too. They bring us in for the software. Why? Because nobody’s going to buy a kiosk by itself. A kiosk by itself doesn’t do anything. It’s the software that does it. Just like your Dell computer doesn’t do anything.

    It’s the Microsoft and the other applications that you put on it, that’s the reason you’re buying the computer. So it works the same way on the kiosk. We’re agnostic. So it’s funny, we built this beautiful restaurant of the future in our headquarters here that people can come in and they can see everything in a working environment, but then after they realize we want a kiosk or we want KDS or we want mobile, whatever it is, we take them next door into our showroom and there we have everything.

    In there they can decide do we want a wall mount, do we want a tabletop, do we want freestanding, do we want a 15-inch, a 21-inch, a 24-inch, a 32 – you know, whatever they want. Do we want it in a portable fashion where it’s truly mobile? All of those options are there, but the software at the end of the day, the core that’s running it, it’s the same. It’s the same software. And you’re right, that’s exactly what we spent our time building, was software regardless of form factor that will work the same.

    And the key to this is that somebody can operate it with no training. So you don’t need to – our competitors in the kiosk space, for the most part, fall into two categories. There are POS companies that turn their POS system sideways and say now it’s a kiosk. Well, that doesn’t work. Or they’re writing an app on an iPad, and that clearly doesn’t work either. So really the advantage in which you were talking about online and now going in store with a kiosk, one of the great things about that is the marketing team and the brand owners can now curate that user experience much like they do with the online experience.

    So you can control and provide that consumer the absolute best experience, where before you had a cashier and maybe you taught them at the end to say, hey, at the burger place, do you want fries with that? Okay, and more people buy fries because the cashier asked them if they wanted fries. However, if I’m ordering a salad the likelihood that I’m going to buy fries is pretty low. However, I might take a fruit cup, I might take a healthy treat.

    So being able to, again, pair offerings to the items that that consumer would like increases the average ticket and improves the experience for that consumer. You also eliminate all the errors, right? Because now you’re putting it in yourself. How many times have you gone and said, “Listen, I’d like a hamburger – I’ll have a cheeseburger with extra ketchup, no pickles,” so they go, “Got, it extra pickles, no ketchup.” You’re like, no.

    So there’s a whole host of reasons why that experience is better and could be faster, because maybe you could only afford to put one cashier in there, but you could put a whole slew of kiosks in there for a fraction of the price of one cashier. Well now you eliminate wait times and you can redeploy personnel into the actual prep of food and improving consumer experience.

    Alan Shimel: Yep. There’s another issue I wanted you to touch on, Sam, and that is really one of the inherent advantages of modern software and whether it’s an app, think of it as an app, or it’s just portable software that’s not particularly tied to – hardwired, if you will, into the form factor of hardware, the ability to update on the fly. Right? You change your menu items, you change your price, your running specials, or I mean really, really big functionality – we’re going to start accepting PayPal or Apple Pay or Google Pay or whatever the – we’re going to start taking bitcoin.

    I don’t care how you want to pay for it. But right? We need to update that. By having it all dependent on software, not burned into the silicon, we do that as well. How does GRUBBRR handle that? Like the whole update process?

    Sam Zietz: Yeah. So first off, we can update everything in real time as well as – so we can also be notified before even the client knows that there’s an issue with software. So maybe their internet went down because their provider – there was a problem, whatever. Many times we’re calling them and saying, “Hey, your internet’s out.” Oh, wow. Somebody was in the closet and unplugged the router or whatever and, boom, it’s back up.

    But you’re talking about an entire ecosystem. So because we have the ecosystem instead of a bunch of disparate pieces of technology in there, you’re absolutely right. You make one change. So price would be an example. If we want to change up a price it changes on a kiosk, it’ll change in the POS if they’re using a POS. It will also change on their digital signage, so the menu board above.

    Great. We want to change the price. Now let’s say you’re out of avocados. Boom. Now guacamole comes off the menu, so now it’s not even on the menu board if you don’t want it to be. If you run happy hour, great. At 5:00 we change the price, at 7:00 we change it back.

    There’s none of that whiteout or cardboard being take up with those changes. We’ve also integrated –

    Alan Shimel: [Inaudible comment]

    Sam Zietz: – AI and machine learning into it, so based on weather, time of year, time of day, order frequency, items will move up or down on the menu. Because we all go left to right. So what you want to do is you want to feature the most popular items or the items that that consumer’s most likely to order at that point of time to the left so that they can then make their decision quicker and move on in the ordering process.

    Alan Shimel: Excellent. Sam, we’re running low on time. I did want to mention, I know you guys recently announced a deal with Samsung, I believe, which is probably one of the largest – I’m going to assume one of the largest kiosk producers in the world – to be powered by GRUBBRR. Do you want to tell us a little bit?

    Sam Zietz: Yeah. So Samsung is obviously a very large company. I think they’re the sixth most recognizable brand in the world. They announced on June 30th that they’re entering the kiosk space. I would bet that in short order they will probably be the 800-pound gorilla in the kiosk space. What they’ve really done is they’ve democratized it, bringing that price standpoint down so it’s affordable to everybody.

    So you’re going to have a lower price. But traditionally kiosks were kind of hobbled together. They were a shell with a whole bunch of other pieces of technology kind of plugged in to make it look like it was one thing, but it was really five or six things. Samsung has truly built one slick unit that has it all built, which has allowed them to eliminate points of failure so the unit will be more successful. Obviously nobody builds screens as effectively as they do.

    In fact, they also have it so from touching it you can’t catch bacteria or COVID or any of that. But the exciting thing for us is, again, as great as a piece of software is, no one is going to buy a kiosk unless it does something, and that’s where we come in. We provide the true value proposition that powers it, and by buying the kiosk with our software you end up reducing OPEX or labor or at least solving for labor when you can’t even find it. More importantly, you increase your revenue.

    Typically, our clients see a 12 to 22 percent uplift in average ticket because people will buy more as a result of that curated experience, and we improve customer experience. So those are the value propositions there, but it’s exciting. When you partner with somebody like Samsung it’s not just here in the US. It’s worldwide. And they’ve got unbelievable reach.

    Alan Shimel: Oh, yeah. We’ve dealt with them. I mean, just another example, no pun and no irony intended, but software is eating the world. Hey, Sam, you know what we didn’t tell people? Where can get they go get more information about GRUBBRR?

    Sam Zietz: Our website’s probably the best place, GRUBBRR.com, G-R-U, double B, double R dot com. So, yeah.

    Alan Shimel: Excellent. Alright, man. Hey, say hello to the family. Best of luck with GRUBBRR. Maybe we’ll be ordering somewhere on some GRUBBRR software soon out there. Check it out. Full disclosure. I know Sam a long time, maybe 20 years. Happy to see him doing well with this and playing in the software game. Sam, be well, and we’ll speak to you soon. Come back on and keep us posted.

    Sam Zietz: Alright, Al. Thank you again for having me on.

    Alan Shimel: Alrighty. Sam Zietz from GRUBBRR here on TechStrong TV. We’re going to take a break. We’ll be right back with our next guest.

    [End of Audio]

  • Fighting Deployment Anxiety: 5 Tips from the Pros

    Fighting Deployment Anxiety: 5 Tips from the Pros

    You know the feeling: You’ve put in hours of work developing a new feature. It has gone through QA, been tested and passed all stakeholder inspections, and now you’re ready to deploy. Despite your experience and preparation, you have a pit in your stomach. What if something goes wrong and it brings your app to its knees? What if it doesn’t function in your production environment the way it’s supposed to? We’ve all been there. Fortunately, we also have some ways to help.

    Electric Cloud CTO Anders Wallgren recently participated on a webinar with Gene Kim, CTO, researcher and co-author of “The Phoenix Project” and “The DevOps Handbook.” Hosted by devopsy.kinsta.cloud Editor in Chief Alan Shimel, the webinar addresses lessons learn from large-scale DevOps transformations, the business value of DevOps and some of the best tips and tricks for fighting deployment anxiety. We pulled out the top five tips and tricks from Kim and Wallgren for making deployment worries a thing of the past.

    Tip 1: Automate Your Deployment

    A theme throughout the webinar from both Kim and Wallgren was “automation.” One of the big reasons for this is that typically, when you automate your deployments, you’re also automating the diagnosis of problems in those deployments. You can’t always just rely on the exit code of a command-line tool to tell you whether something went right or went wrong. To help keep your deployments healthy, you’ll want to do testing along the way, possibly as a blue-green deployment or a partial deployment. However, if you don’t have automation behind that, it can be difficult to get that accomplished at speed. Without automation, you may start to rely on heroic efforts by individuals—so that every time you are doing a deployment, someone is having to do a figurative tightrope-walk to get everything accomplished. This creates a tough environment for your employees, and can lead to extensive downtime (and lost profits).

    Tip 2: Enable Self-Service Deployments to Any Infrastructure

    You’re probably wondering why this is a separate topic from automated deployments. That’s because the majority of deployments that occur in a given release pipeline aren’t going into production. Most deployments end up in testing environments (for performance testing, regression testing or just developer testing). It’s also important that you give your engineers the ability to use the same deployment methodology (artifacts, process definition, environment definition, etc.) regardless of the location to where they are deploying. From a cost perspective, allowing QA to test on a local Kubernetes cluster might be more cost-effective for your enterprise than running tests on Amazon Container Service. But, allowing teams to use the same approved automation as part of every deployment—to any location—means a more thoroughly rehearsed and therefore less anxiety-inducing deployment.

    The ability to do self-service deployments also gives your teams the ability to move substantially faster when they need to deploy something for testing by avoiding the need to open a ticket and get your Ops teams involved. By allowing self-service deployments, you can avoid the process of running around to find the right person to accomplish the deployment you need to run, and empower your organization to react and build more autonomously across different groups. The result is better-tested and built deployments (resulting in lower deployment stress and fewer errors).

    Tip 3: Self-Service Environments

    We’re continuing to roll with the theme of automation, but this time we’re talking about self-service environments. More often than not, we’re working with complex distributed apps. This means things such as a containerized microservice application, DBMSs, messaging, key value stores, legacy applications and third-party vendors that we need to integrate with—all things that make our deployments complicated. Being able to consistently provision complex environments is a very important part of being able to successfully recreate a deployment as you promote the application through its life cycle.

    It’s important to make sure that your engineers, and in particular, your QA and development engineers, have easy access to environments and that they’re not standing around waiting for access. When you don’t have the ability to get VMs or containers provisioned and configured correctly to receive your application, you run into problems. One of these problems is that your ability to test rapidly just became much more difficult. When you can’t get a near-production quality environment stood up in a few minutes, it means that your bug fix that requires just a few lines of code could potentially take weeks to test. Suddenly you need to requisition a set of VMs to test on (which could take weeks) and another day or two to do the deployment, and only then can you complete your tests. Things become painfully slow. And, when it comes to testing and fixing bugs, slow equals stress.

    Tip 4: Artifact Repositories

    Want to feel more confident about your releases? Look at your artifact repositories. Use of a shared artifact repository in production environments has been shown to be a good are a really good predictor of deployment success. If you’re not versioning your binaries, and have little insight into where binaries are coming from and how they were built, it can lead to failed deployments.

    It may not be easy or simple to get your artifact repositories in line, but it’s a labor that will pay massive dividends in the long term. Electric Cloud worked with a massive online mortgage company that had the challenge of deploying large artifacts (gigabytes) into multiple data centers. To get everything up to speed, it was necessary to transfer those artifacts out of their build and test infrastructure and into their pre-production and production infrastructure. Because of the size of the artifacts and concerns about worldwide availability for the files, Electric Cloud worked with this financial services company to use Amazon S3 as the backing store for the repository server to create a long-term solution that is flexible and scalable.

    Tip 5: Security and Auditability

    If you work in a regulated industry, already know the heartburn auditability and governance can cause. Security is one of—if not the single—most important aspect of many application delivery pipelines. The reality is, we are just beginning to scratch the surface of the problems we will see the in the future when it comes to infrastructures getting hacked. So what’s our tip? Again, it comes back to automation. At ElectricCloud, there is a saying: Automation is auditing, automation is documentation.

    The idea behind this is that by automating your deployment tasks, you are essentially creating a very real and tangible paper trail that shows what you intend to do (the automation definition) and a report of exactly what happened (the automation logs). When you rely on manual deployments, you suddenly take an aspect of repeatability and predictability out of your workflow. At that point, you are forced to report based on people’s spreadsheets, emails and memories. This is one of those things that doesn’t become a big deal until it’s a really big deal, and—to borrow another saying—an ounce of prevention is worth a pound of cure. In the case of auditability and security, being able to retrace your steps because your steps are always the same is a fairly foolproof method to making your audits much more smooth.

    To provide a real-world example for how automation can make auditing and security much less painful, one of ElectricCloud’s clients is an aerospace customer with very stringent and demanding security standards. In the past, at the end of each release, it would have a two-week process where everybody had to sit down and compile a list of every single check-in deployed as part of that release. They had to understand where it got built and exactly how it was tested, and then assemble all of that information in a report. It was an extremely time-consuming, but seemingly necessary process. However, by automating many of the steps in the pipeline, the audit response effort went from a two-week process to just a few hours. They accomplished this because 99 percent of the information they needed was in the automation system and was simply scraped as part of process. The task went from manually pulling that data to just getting into it consumable formats.

    Summary

    By now you’ve certainly seen a theme emerge in our recommendations for reducing the stress of deployments—namely, automate! By putting effort into automation and streamlining your pipeline, you can take what was once a very labor-intensive and sometimes stomach-churning process and make it much more enjoyable. Not only will this save you time and money in the long run, but it will also allow you to focus on building better software, doing more deployments and focusing on the tasks that bring your business and your customers real value.

    For more details on how you can relieve your deployment anxiety, and to hear the rest of the discussion focusing on the lessons learned from large-scale enterprise DevOps transformations and the business value of DevOps, watch the full replay.

    About the Author / Sam Fell

    sam-fellSam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft. Follow him on Twitter and connect with him on LinkedIn.