Tag: adopting DevOps

  • Why SREs Are Critical to DevOps

    Why SREs Are Critical to DevOps

    Although a relatively new concept, site reliability engineers (SREs) have become crucial for DevOps teams, helping to solve an array of operational problems such as network availability and user experience. However, in previous years, some people have questioned the longevity of such a role. 

    This article will discuss several reasons why site reliability engineering roles are here to stay and why they have become critical to DevOps. 

    What Are Site Reliability Engineers (SREs)?

    A site reliability engineer helps connect development teams and IT operations by completing tasks previously assigned to operational roles. SREs use a range of automation tools for troubleshooting purposes, creating software systems that are both scalable and reliable.

    The role revolves around automation and standardization, as cloud systems become increasingly prevalent. SREs also play a vital role in ensuring the user experience of systems is of the highest standard.

    Why Site Reliability Engineering Roles Are Here to Stay

    Let’s take a look at two of the primary reasons SRE roles are here to stay. 

    User Expectations

    The key reason for the rise in popularity and the expected longevity of site reliability engineering roles is user experience. In the modern climate, user expectations are very high and more dedicated roles are required to help deliver a service that is not only acceptable but attempts to exceed user expectations.

    Even back in the 2010s, users were much more patient in terms of website load speeds and how quickly they could access information. Even crashes and load failures were tolerated without the user exiting a website.

    However, that has all changed due to the competitiveness of the market, as well as the growth of remote working, which has increased dependency on online resources. This means that if a service is unavailable for any period, users are unable to do their job. 

    An SRE’s role includes optimizing systems, ensuring they perform at the required level and that resources are always available to those that need them. This makes SREs critical to DevOps teams that may not have the capacity to focus on meeting user expectations sufficiently. 

    The Complexity of Software Architectures

    Another factor that has added a lot of value to the role of an SRE is their ability to provide much-needed support for software environments and architectures that continue to develop in terms of complexity. Kubernetes is one such architecture that requires dedicated attention. 

    Applications that are distributed across systems such as Kubernetes and other cloud-native platforms require specialized personnel that have the necessary knowledge and experience. Machine learning is also becoming more prevalent and requires special focus from a performance perspective. In 2020, just more than 22% of companies had machine learning models in production for one to two years.

    This level of complexity is only expected to grow further over the coming years as cloud-native systems become the norm. This is why new roles must be created that go beyond that of a normal IT engineer. 

    Challenges for SRE Roles

    Like any IT role, the role of a site reliability engineer always faces challenges that have led people to question whether SREs are a long-term solution or whether it is a niche specialization. 

    A Lack Of Opportunity Away From Hyperscale Companies

    The role of an SRE was created by hyperscale companies like Google that manage extremely large IT systems. For companies that do not have such a wide and varied IT infrastructure on a global scale, there are questions about whether such a role is necessary. 

    However, as previously mentioned, the growth of cloud-native technology shows no sign of slowing and, with this growth, opportunities for SREs at smaller organizations may arise. 

    The Role of an SRE is Considered Obscure

    The ambiguity of an SRE role can be considered a downfall in some cases, with many businesses unsure of what these professionals offer when compared to a traditional systems engineer. In many cases, SREs are deemed to be a hybrid of a software engineer and an IT operations role. 

    Fortunately, DevOps has realized the potential of SREs and their ability to provide an important bridge between developers and engineers, helping to achieve dedicated tasks to a high standard. 

    SREs Vs. DevOps

    Although both roles are connected and share some similarities, there are some clear differences.

    • Processes – DevOps has full visibility into the development environment which allows them to make changes from the initial development stages through to production. SREs, on the other hand, only have visibility into the production process, allowing them to make suggestions to ensure performance levels are maintained.
    • Implementation – The task of implementing new features on a system falls on the DevOps team. Meanwhile, SREs are tasked with ensuring the new features do not cause any system failures or impact performance during the production stage.
    • Key Focus – The primary focus of a site reliability engineer is to ensure the system’s reliability, availability and scalability. DevOps focuses on how quickly product development is completed, as well as its continuity.
    • Structure – The structure of an SRE team and a DevOps team have obvious differences. SRE teams are made up of individuals who have similar skill sets relating to development and operations. Whereas DevOps teams consist of professionals who have specific roles related to individual aspects of the project. These roles can include the team leader, product owner, cloud architect, software developer, QA engineer, system administrator, release manager and more.
    • Tools – DevOps teams often use tools such as integrated development environments (IDEs) when developing a product. These can include Jenkins (continuous integration and continuous development), JIRA (change management), Splunk (log monitoring) and GitHub (distributed version control). SREs commonly use tools such as Prometheus and Grafana (collection and visualization of metrics, such as CPU usage and available disk space), OP5 and PagerDuty (incident alerts), Ansible and Kubernetes (container orchestration) as well as a range of cloud platforms.
    • Bug Reporting – DevOps debug code whenever a bug is reported in the end product. SREs are not involved with debugging from a development perspective and are only required to perform such tasks if there is a production outage, there are infrastructure issues or perhaps if they are dealing with common AWS misconfigurations.
    • Measuring Performance – The typical metrics that DevOps uses to measure performance are deployment frequency and deployment failure rate. SREs measure service level objectives (SLOs), service level indicators (SLIs), service level agreements (SLAs) and error budgets.
    • Incident Handling – In the case of incident handling, DevOps teams work to mitigate an issue based on the feedback provided. SREs then analyze the issues post-incident, including the root cause of the issue. This is then documented and provided to the developers to fix. 

    Why SRE Roles Are Critical to DevOps – Conclusion

    As you can see, the two roles differ significantly but SREs can play a critical role in ensuring the DevOps team delivers a product that offers maximum performance. 

    The core benefits of employing professionals in a site reliability engineer capacity are high levels of product performance and reliability to meet user expectations while helping to manage complex IT architecture. 

    In the future, organizations that manage a large amount of cloud-based IT assets may struggle to deliver efficient products without such professionals. As such, demand for SRE roles is likely to grow. 

  • Is DevOps Dead? I Don’t Think So!

    Is DevOps Dead? I Don’t Think So!

    A lesson I have learned over my 30 years in the tech world is that technology and frameworks never truly die—they evolve and they grow. When I read a recent article proclaiming, “DevOps is dead!” and that we should all be embracing platform engineering, I had a chuckle.

    No, DevOps isn’t dead, and rumors of its demise have been greatly exaggerated. In fact, DevOps is more alive than ever and the truth is, it is going wherever software goes. When I went back and read the article again, I realized that it appeared on a website owned by a venture capital (VC) company and that the article itself was a sponsored post from a company promoting platform engineering. That’s a good reminder to take that article with a grain of salt. I also realized that the headline was meant to be controversial, if not downright clickbait.

    That said, I feel that the article demands a rebuttal. To be fair to the author of that article, I believe the point they were trying to make is that there is a major issue with DevOps—we have put too much on the developers’ plates, and that one more straw may break the proverbial camel’s back. Certainly, this is a valid point. We need to balance what we ask our developers to do in relation to the rest of the team. We see this with security in DevSecOps; we see it with testing and we certainly see it with operations. In fact, in many ways, the rise of the SRE has better defined the ops role thereby lessening the load on developers.

    I have no doubt that platform engineering will also lessen the load on developers and better define the role of a platform engineer. However, SRE did not kill DevOps and neither will platform engineering. At one time, it was very fashionable to talk about a full-stack developer. Today, many people think that the so-called full-stack developer is a myth and that role is not really what is needed in most organizations. The job of a developer, though, is never and will never be easy, even with the advent of AI/ML-generated code. The developer always has many plates spinning in the air at any given time. And to that point, the high levels of compensation they are paid is not unwarranted nor is it unearned.

    I look forward to seeing how the platform engineer role and platform engineering as a practice evolve and how they interact with SREs and DevOps teams as well as developers, security testers, etc., but I am fairly certain that no matter how the role evolves, it will not be the death knell for DevOps.

    As we proclaimed for our upcoming DevOps Experience event on November 16, 2022, it is going where no DevOps has gone before. We see DevOps-of-things; we see DevOps at the edge. We see distributed DevOps, too. DevOps has taken root in our software development life cycle and beyond. While the frameworks may change and evolve, DevOps changes and evolves with it.

    If you say DevOps is dead, I disagree. I say long live DevOps!

  • 5 Reasons to Adopt DevOps

    5 Reasons to Adopt DevOps

    DevOps IT methodologies are taking the development industry by storm. Some call DevOps great for software development. Others find it ideal for pushing out regular software updates and pursuing continuous delivery for clients.

    If you do not know what DevOps is or why your business should adopt DevOps, read on. We’ll break down five reasons why your organization should adopt DevOps at the earliest opportunity.

    What is DevOps?

    In a nutshell, DevOps is short for “development” and “operations.” It’s a software development and programming methodology that helps teams execute ideas more quickly and pursue continuous deployment for organizations and clients. In web and mobile app development, DevOps can be very beneficial thanks to its agility, responsiveness, and versatility.

    Many organizations think of DevOps as some new approach or technology, but it’s actually been around for some time. This approach to IT delivery combines special practices, philosophies, and tools to help mitigate bottlenecks from operations and development.

    Specifically, DevOps combines both development and operations principles to some extent. In this way, most of the major aspects of software or app development are unified. This, in turn, allows teams to respond more capably to shifting project demands and bugs.

    Furthermore, DevOps focuses on organizing and separating “silos” in organizations. In this way, teams or individual workers can take responsibility for a given project. This is superior to separating tasks by individual roles or team labels. DevOps’ advantages mean it’s being used in many different and unique industries, from fintech to medical communication services, and manufacturing.

    However, many businesses are wary about switching to DevOps or any other methodology because it:

    • Requires a major culture switch in workers. It is never easy to shift methodologies, especially when the methodology in question is as complex as DevOps.
    • It is not a one-size-fits-all solution. For DevOps to be successful, your team has to embrace it thoroughly, understand and master its principles, and spend some time practicing.

    Even with these potential downsides, it’s still a very good idea to get your team on board with shifting to DevOps sooner rather than later. Many competing organizations have already done this!

    Benefits of DevOps for Businesses

    DevOps can provide numerous important advantages for businesses just like yours, regardless of industry, niche, or size. Let’s take a look at the five big advantages one by one.

    Better Team Collaboration

    For starters, DevOps often leads to increased team collaboration. Specifically, it allows your development and operations teams or departments to communicate and collaborate much more easily than before.

    In turn, this translates into freer communication between both departments and more trust between individual team members. Your development and operations teams can share their inputs, knowledge, and specific understandings of tools, code, or client desires.

    Think of DevOps as unifying the two teams in your organization. A unified team is one that’s better prepared to respond to changing industry trends, new consumer tastes, or sudden objective shifts that you can’t avoid.

    DevOps is so good at fostering team collaboration because it’s an agile methodology. Agile methodologies are ideal for simplifying complex tasks into more manageable or smaller pieces. This results in a more iterative, manageable planning and development process across the board.

    Greater Security

    DevOps may also lead to greater developmental security. DevSecOps, a broader version of DevOps, involves merging your development and operations teams with your security team.

    In essence, you shift security focuses and practices to the left of your development pipeline. Security checks, cloud monitoring, and regular examinations of code to prevent breaches or vulnerabilities happen earlier in the development process as opposed to later, closer to launch (and when problems or bugs are always harder to fix).

    DevSecOps lets your team identify and fix security issues earlier and more regularly. Any software products or apps your team puts out should be tighter in terms of code security and should be harder to breach or break by any bad actors or hackers.

    Improved Efficiency

    DevOps is very beneficial for organizations because it can improve efficiency in many key ways. DevOps culture and methodologies often require you to use automated tools such as Docker, Git, AWS, and more.

    With these automated tools, your DevOps team can quickly identify bottlenecks or potential issues and take corrective actions as needed without having to waste time. Remember, DevOps inherently means that your teams are more collaborative and communicative, so you don’t need to spend time sending messages between both departments unnecessarily.

    DevOps is very high velocity, infusing your development team with more agility and flexibility than ever before. Naturally, this is a majorly competitive advantage; it allows your team to iterate and innovate more rapidly and regularly than your competitors.

    Faster Bug Resolution

    However, DevOps can also prove advantageous to your organization by helping your company solve discovered bugs more quickly. CI or continuous integration is a core element in any DevOps team or department.

    In a nutshell, this involves checking the final build and any related code regularly. Since more checks occur under a DevOps methodology, that means your teams will be more likely to discover bugs or issues with a software product before launch.

    Furthermore, this allows your team to constantly make small changes to improve code or repair bugs immediately rather than waiting for them to lead to long-term issues later down the road. This is beneficial since it will help you:

    • Crush bugs before your clients and customers see them
    • Fix bugs before they spiral out of control by deploying patches through the cloud
    • Avoid putting off or delaying software launches
    • And more

    More broadly, DevOps methodologies let you produce smaller releases and smaller changes. Since every code change has to be run through automated testing processes before getting to production, bug fixing is both faster and rarer. 

    More Client Satisfaction

    Lastlty, and perhaps most importantly, DevOps can help your organization produce greater and more consistent client satisfaction overall. After all, the primary goal for any programming or software methodology is to make sure that clients or end-users of software have excellent experiences and don’t have any complaints.

    This is even more important in the modern day when you have to compete against other software development organizations all the time. If you want your organization to be efficient, agile, and organized, DevOps is the way to go.

    DevOps should produce software with:

    • Fewer bugs or other issues
    • More manageable software updates and releases
    • A more integrated team supporting its processes
    • And more

    All of this will contribute to a better initial and long-term experience for clients or end users. In addition, DevOps allows your team to deliver innovative solutions or code changes quickly and easily, allowing your brand overall to improve customer experiences as time goes on.

    In other words, DevOps lets you evolve your product along with the desires of your customers.

    Conclusion

    As you can see, DevOps practices and methodologies are beneficial in more ways than one. Once you adopt DevOps for your organization, you could see improved efficiency, more continuous delivery of online or software-based services and other advantages. Both you and your clients will benefit, so start adopting DevOps across your company today.

  • DevOps World 2022: Why DevOps Needs a Remix

    DevOps World 2022: Why DevOps Needs a Remix

    I was checking out the DevOps World website today to gather information, as Techstrong.TV will be live streaming from the show in Orlando, Florida September 28 and 29, 2022. The theme for this year’s DevOps World is “DevOps Remix.” The more I thought about it, the more it became clear that DevOps Remix is a perfect theme for DevOps World—and for DevOps as a practice.

    What does a DevOps remix mean? Well, I won’t pretend to speak for CloudBees, the event’s host, but here’s what they have on the DevOps World website:

    “The tempo will be faster, more energized, and more harmonious in keeping with the accelerated pace of the DevOps transformation. Progressive delivery, value stream management, and everything from AIOps to XOps are now part of the mix creating new paths, new beats, and faster code releases.”

    That’s what a DevOps remix means to them; here’s what DevOps remix means to me.

    I believe a DevOps remix speaks to the continuing maturation of DevOps as a methodology and a practice and to the DevOps market and community. DevOps is no longer nebulous; there’s no longer a question of “Is it real or not? What exactly is DevOps?” kind of thing. No, DevOps is very much a player in the software development life cycle (SDLC). So much so that as digital transformation continues to involve software in places it hasn’t been before, DevOps is helping it get there. DevOps is going places it has never been before.

    Techstrong Group’s own DevOps Experience event, now in its fifth year and coming this November, has a similar theme: DevOps Everywhere. DevOps, as part of the CI/CD pipeline, still exists, but DevOps today is so much more. To be successful today, organizations large and small (but especially enterprises) need to take DevOps fundamentals and implement them whenever and wherever they are building, deploying and managing software.

    Another reason the idea of a remix is so appropriate is that, as the world emerges from COVID-19 lockdowns, there is something comforting about revisiting in-person events, conferences and training—the ‘normal’ industry activities and events that happened before the pandemic. For those of us in the DevOps space, DevOps World is one of those things. I have been going to DevOps World since before it was even called DevOps World—when it was Jenkins World. There’s a remix for you!  

    DevOps does need a remix, and it’s happening right now. While I do think it’s great to be able to resume many of the same activities, go to the conferences and get training, I don’t expect this year’s DevOps World to be like previous editions in San Francisco or online. That’s part of what makes it such a terrific event—a mix of the old, the new, the tried and true, the cutting edge and the familiar. So, if you consider yourself a member of the DevOps community and can make it to Orlando at the end of September, you should consider being part of the DevOps Remix.

    This year, DevOps World will be held in Orlando, Florida, at the World Marriott Center. The CloudBees folks have published a discount code, DW22, to use when registering that should save you some money on a full ticket for the show, including some training, some great sessions and interactive activities. We can’t wait to see you there for the DevOps Remix!

  • 5 Best Practices for Software Development in the Hybrid Workplace 

    5 Best Practices for Software Development in the Hybrid Workplace 

    Over the years, software teams have gradually become more dispersed as technology advancements facilitated hybrid work and allowed teams to collaborate, create and innovate remotely. However, this trend accelerated and became more of a mainstream norm over the last two years during the COVID-19 pandemic, requiring newly dispersed teams to develop a more streamlined hybrid approach to the development process. 

    When seeking to implement a hybrid environment, it’s important for development leaders to consider how best to coordinate a distributed workforce across time zones, how to track projects effectively and ensure accountability. At Lenovo, these are considerations the Cloud & Software team has had to navigate since its inception due to the global nature of our business. To be effective in a hybrid environment, we adopted certain processes and tools that facilitated open communication and cross-collaboration no matter the location. After evaluating various hybrid methods, here are five best practices that stand out. 

    1. Adapt the development process to suit a hybrid setting

    In a hybrid work environment, it can be challenging to consistently bring the entire team together at a specific point in time to estimate work, refine issues or plan sprints. Coordinating between busy calendars and multiple time zones is an inefficient use of time, especially when many software projects are deadline-driven. Moreover, many developers are highly creative and want fewer coordinated meetings and more time to contribute when they want, at their own pace.

    To navigate these challenges, program managers can adapt the development process to be less regimented and more flexible. Facilitating such events as estimation, sprint planning and backlog refinement in an asynchronous manner within a virtual team workspace can allow all team members, no matter where they are located, to contribute, feel heard and seen and receive feedback from their teammates. Such programs can also enable an automatic way to log decisions and house required software documentation.

    2. Establish a single source (or tool) of truth

    Many organizations relate to the challenge of having project data spread across multiple tools. While the development team tracks day-to-day work in one tool, other stakeholders are tracking goals and team KPIs in an entirely different set of tools which can lead to misalignment, something that can be exacerbated in a hybrid environment.

    To overcome this challenge, development teams can establish one central location using a work management tool where past, current and future projects live and that all team members can access, reference and share. By leveraging this tool as a single source of truth, team managers can bring visibility and transparency to the development and program management processes while creating stronger alignment.

    3. Enable full transparency in decision making

    Our team at Lenovo follows a strict process of documenting the decisions taken throughout the development process and we make that documentation available for all team members to access within the team workspace. 

    This can be a beneficial practice for project managers that want to strengthen accountability. Encouraging such transparency enables team members and stakeholders to reference the reasoning behind a specific decision, especially if concerns arise later in the project life cycle process. The result is better alignment across the organization.

    4. Establish a facilitator for each ritual

    To maintain a healthy hybrid environment, assigning an owner to each Agile event can make all the difference. By serving as a facilitator, that owner would then be responsible for aligning everyone to a pre-meeting agenda and goal, allowing teams to prepare and review issues and tickets ahead of time. This added organizational step can result in a more streamlined meeting cadence and more productive discussions.

    5. Automate and leverage efficient tools

    Finding the right combination of tools to support a team’s specific collaboration needs is imperative to a successful hybrid development environment. Seamless and automated collaboration is the key, but there is no one-size-fits-all solution mix. Development leaders should consider tailoring their portfolio of tools around specific needs and look for programs that can help keep a dispersed team on track and synchronized (via direct messaging, ongoing team conversation chats or face-to-face virtual meetings, for example), as well as those that can ensure visibility and improve efficiencies. Whatever external programs are selected, however, should be hosted internally behind the company firewall and VPN for added security. 

    The modern workplace has changed dramatically in the last two years—in many ways permanently—with flexible, remote and hybrid work driving the greatest transformation of collaboration for software development teams across all sectors. By adapting to new hybrid development strategies, enabling transparency in decision-making and leveraging automation for greater efficiency, the development teams of today and tomorrow will be well equipped to more easily adapt to future disruptions in the workplace. 

  • 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]

  • Best of 2021 – 6 Signs You’re Doing DevOps Correctly

    Best of 2021 – 6 Signs You’re Doing DevOps Correctly

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the twenty-first in our series of the Best of 2021.

    A lot of organizations claim to be DevOps-focused because they use specific tools and loosely follow certain practices. But to really be a DevOps-centric organization, there are specific DevOps principles and processes that ensure your organization is as optimized and automated as possible. To ensure that you’re not just using the DevOps title without following the underlying principles as an organization, here are six signs you’re actually doing it right.

    Deployment Is Fully Automated

    Having deployment completely automated from start to finish is one of the more apparent signs that you’re following the DevOps principles correctly. Automated deployment is a huge time saver, especially when things go wrong and you need to revert to a previous build version quickly. Manual deployments can lead to problems often caused by human error. Having a strong focus on automating processes is a core belief DevOps-centric organizations should hold dearly. Automation increases an organization’s efficiency and reduces errors.

    You Have Frequent and Rapid Release Cycles

    As soon as software is ready to go, it should be deployed and delivered to the customers. We live in a world where competitors are building better software daily. It’s to an organization’s benefit that new features and bug fixes are continuously deployed to stay ahead of the competition. DevOps is all about continuous delivery, so having developers produce new code and quickly release it into production is one of DevOps’ core features.

    You’re Using The Right Tools and Platforms

    The tools you use to deploy features and fixes should make building applications easy and testing straightforward. You should generally be able to build, test and deploy to production with no hiccups along the way. If you’re spending a lot of time fixing any issues that occur, then you might not have the right tools or processes in place. Fortunately, today there are extensive continuous integration software options that can adapt to any current existing infrastructure. Although tools are an essential piece of DevOps, it’s important to remember that while tools make DevOps possible, it’s the practices that truly make the changes happen.

    You Have a Continuous Feedback Loop

    Nothing is perfect in its first iteration, and errors are bound to occur along the way. You must have a continuous feedback loop system to detect when and where things go wrong. Having software tools that monitor processes and quickly inform you when errors occur will make fixing issues that pop up easier and faster.

    If you have a system set up to identify issues, fix them and improve upon them, you’re doing DevOps correctly. If you run into problems and simply fix them without taking the time to analyze why they occurred or how to prevent them from appearing again, you might want to consider making some changes.

    Development and Operations Groups Work Together

    Communication between development, testing and IT operations groups is vital for DevOps success. Cooperation between these different groups ensures that the pipeline will run smoothly. Any problems that do occur will be faster to fix when developers and IT operations personnel can easily coordinate with one another.

    Goals and Objectives Are Clearly Established

    While communication between different teams is essential, having clearly defined goals and objectives that everyone is striving toward is just as important. Ultimately, all the teams have the same goal: making the organization more efficient; however, the individual practices they follow to make that happen might differ. Team members should be aware of precise requirements that need to be met for a goal to be reached, instead of making assumptions or leaving it to chance.

  • 3 Building Blocks for Enterprise Digital Transformation

    3 Building Blocks for Enterprise Digital Transformation

    DevOps has gone from a new idea to a buzzword in every boardroom over the last decade. With society increasing its reliance on digitization and pushing their preferences for speed and convenience, enterprises of all types have had to change their business culture to help their teams to work together with greater speed and autonomy.

    While the pandemic has undoubtedly heightened the importance of DevOps in the workplace, its widespread use predates the last few years. HGS Digital research from as far back as 2018 found that only 3% of software development businesses had never heard of DevOps. The 2021: Future of the Atlassian Ecosystem report revealed that 54% of organizations have implemented a DevOps strategy—up from 48% in 2020. A further 27% of respondents are hoping to adopt a DevOps strategy in the next three years.

    Indeed, DevOps is now mainstream, and the uptick in job listings for ‘DevOps engineers’—as well as enterprises’ quickness to tout their ‘experienced DevOps teams’—is perhaps further evidence of this. However, some of these postings and sentiments can also be considered red flags as they suggest that organizations are applying DevOps practices to isolated teams. Or worse, they are simply labeling traditional engineering roles with the DevOps label rather than implementing a complete mindset shift that applies to the entire organization and enables it to release reliable products at a much faster pace.

    With this in mind, here are three key building blocks for enterprises looking to avoid common downfalls and effectively scale their DevOps strategies. These will help them change the way they work and think across all aspects of development and operations.

    Changing Culture and Empowering Employees

    Everyone needs to be on board for DevOps to be successful, and buy-in is strongly dependent on the business culture they are working within. For example, Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations. And the reasons why have to do with issues around organizational learning and change.

    To put it another way, if employees don’t understand DevOps’ deeper thinking and benefits both to them personally and to the wider group, they will naturally be resistant to the change. It is, after all, an entirely new way of thinking for many departments, especially operations teams who traditionally reduce risk by minimizing change and taking things slowly. DevOps encourages them to speed up with minor changes delivered through continuous integration operating in a fail-fast and often fail-forward pipeline.

    Therefore, educating employees is vital for success. In particular, organizations should give staff a clear idea of how it will feel to work differently. Shared definitions of success, shared vocabulary and shared visibility of the work to be done is key. With that—and along with sharing actionable insights that teams can apply to their work and then observe the results—no matter where they are in the pipeline, the real value of DevOps can be achieved.

    The reality is that people are the most critical component of any DevOps transformation, making their commitment to the cause non-negotiable for success. Despite the tech-heavy nature of software development, soft skills like communication, collaboration, flexibility and decision-making must be prioritized as much as security, coding and infrastructure knowledge. It’s imperative that all businesses look to adopt a DevOps mindset and implement these traits into their culture in the future.

    Applying Four Fundamental Processes to the Foundation of DevOps

    That said, a successful DevOps transformation can’t happen unless enterprises step away from traditional IT’s ‘trust but verify’ methodology. Instead, they must incorporate a set of essential processes that empower everyone to work more efficiently and effectively toward achieving faster, high-quality software delivery to suit the end-user’s needs. These fundamental processes include collaboration, automation, continuous integration and continuous delivery (CI/CD) and monitoring.

    While collaboration has been one of the most significant rallying cries for enabling globally distributed IT teams to align their goals and meet their objectives, automation has also been highly crucial. Many of those ingrained in DevOps environments will tell you that automation is what makes DevOps highly valuable. It helps teams achieve high levels of efficiency and allows employees to focus more on complex problems and less on repetitive tasks. When a company’s automation strategy is aligned with its broader business goals, it can help deliver value at scale.

    But as is the nature of software development, problems can arise. And this is where continuous integration and delivery come into play; it forces developers to merge their source code updates with others far more frequently than they might otherwise choose to. Operations teams can ensure they’re not creating a bottleneck with manual testing to get releases out to users. The approach means smaller changesets; helping to identify, target and resolve bugs more efficiently. This increases the flow of work, the quality of releases and helps to avoid nasty problems at the end of the development cycle.

    But there’s no point in having a speedy, heavily automated CI/CD process with a genuinely collaborative culture if enterprises don’t take the time to measure what’s working and assess which actions need to be improved. This is why an effective DevOps plan needs to be built on the mantra ‘implement, measure and improve’. After all, DevOps is about maximizing value and efficiency through increased visibility of work and constant feedback. Measuring real-time metrics becomes vital to ensure business’ transformations are in line with their objectives at all times. If enterprises stick to these fundamentals, they’re well on their way to a successful DevOps strategy with complete buy-in.

    Adopting the Right Tools for Transformation

    As teams grow and DevOps processes scale, predictable performance is imperative. Therefore, the enterprise’s tools must be available around the clock and should perform at a high level to support their collaborative pipeline.

    But using DevOps tools doesn’t automatically mean organizations are applying DevOps principles. The value of tooling is limited by businesses’ commitment to using them holistically with the sort of culture and processes mentioned above. It is this combination that allows them to transition how they develop and deliver their products. With all that said, it’s important to understand how important it is to adopt the proper toolchain—and the wide variety of choices and combinations available—this is why it’s easy to understand why decision-makers might become overwhelmed.

    After all, there’s a lot to keep in mind. They need to choose tools that step up their collaboration, keep context-switching to a minimum, aid automation, encourage visibility and allow for effective monitoring. But there’s also the risk that they’ll pick the solutions that they feel most comfortable with, which can be counterintuitive to transformation. This approach can lead to a tool binge, bringing on too much technology where integration isn’t a priority, and leaving enterprises with nothing that does the job they need.

    With this in mind, enterprises need to take the time to consult on which tools are right for them while constantly keeping the fundamentals of DevOps in mind. To illustrate just how valuable this is, DORA and Google Cloud’s 2019 State of DevOps report found that the highest performing engineers are 1.5 times more likely to leverage easy-to-use tools. Meanwhile, failure to do this is perhaps a primary reason why a separate study from the DevOps Institute uncovered that the DevOps transformation journey is still arduous for more than 50% of respondents.

    Taking the Next Step Toward DevOps

    A successful DevOps transformation rests on in-depth understanding, mass buy-in and an organization-wide adoption of fundamental principles and practices. When this agile mindset is applied to the people, processes and tools that make up an organization, enterprises can drive significant change across their teams while increasing their products’ reliability, stability and security.

    It’s always important to keep in mind who DevOps is designed to benefit the most—the customer. This mindset is particularly valuable in today’s landscape, where businesses and consumers alike are flush with more choice than ever. With speed and convenience now at the forefront of most people’s purchasing decisions, DevOps can play a huge role in helping organizations strive for greatness and offer the customer something they didn’t even know they needed. Using the above building blocks, organizations of all sizes can dramatically improve their customer experiences and work more efficiently to quickly get the right products into their hands.

  • CircleCI Survey Shows the Need to Prioritize DevOps

    CircleCI Survey Shows the Need to Prioritize DevOps

    A CircleCI survey of 2,013 business leaders in the U.S. and UK published today finds nearly all respondents (97%) recognize that the success of their business within the next year depends on their software development teams. Despite those findings, well over one-third of respondents (39%) admit their organization is challenged when it comes to innovation and acquiring and maintaining developer skills.

    A full 89% of respondents said they also have a good understanding of how to measure the performance of their engineering teams. However, 40% of companies are still using antiquated metrics such as the number of lines of code written, while another 37% measure story points.

    More troubling still, less than one-third of respondents (30%) said they plan to make adoption of DevOps best practices a priority. On the plus side, only 15% of respondents said they are implementing a continuous integration/continuous delivery (CI/CD) platform for the first time.

    The CircleCI survey suggests that improvements in how software is delivered could be worth, on average, up to $126 million per year. Nearly two-thirds of respondents (65%) said their business is involved in digital business transformation initiatives of one kind or another. Another 20% said they have completed one.

    Jim Rose, CircleCI CEO, said it appears that while more organizations now realize how dependent they are on software, many of them have yet to address issues that fundamentally impact developer productivity. For example, more than half (52%) of respondents don’t allow their software developers to choose their own tools, noted Rose. While there is a clear need for a consistent approach to building and deploying applications, Rose noted that DevOps best practices should not require developers to employ a specific set of tools. Developers are only able to truly innovate when they are able to experiment with different tools, said Rose.

    In general, Rose said DevOps adoption tends to go through various cycles. Many organizations today are looking to reduce the number of tools that make up a toolchain. However, those efforts shouldn’t curtail the ability of developers to innovate. A CI/CD platform that provides the foundation for DevOps workflows needs to be easily extensible, noted Rose.

    It’s not clear to what degree adoption of DevOps best practices have stagnated, but the number of organizations that have implemented DevOps across their entire enterprise remains limited. Most organizations have individual teams that might have adopted DevOps to one degree or another. In many cases, those teams are using disparate tools and platforms.

    Most organizations clearly want to be able to build and deploy applications faster. The challenge isn’t so much mastering DevOps platforms as overcoming many of the cultural issues that conspire to limit DevOps adoption. In time, however, the need to rely more on digital processes will force the DevOps issue. As one organization makes advances—thanks in part to their ability to effectively employ DevOps processes—the more keen rival organizations will be to make sure they don’t lose ground. It may be a while before business executives connect the dots between their ability to compete and the degree to which organizations have mastered DevOps, but it’s increasingly apparent that day is not too far off.

  • Pilot Testing DevOps in a Pandemic

    Pilot Testing DevOps in a Pandemic

    Savvy organizations are using the pandemic to drive innovation by pilot testing DevOps. As health experts brace for an exponential rise in COVID-19 cases across the nation and vaccine distribution ramps up, many states and cities are still implementing significant measures to reduce the virus’s spread. As shutdowns impact cities coast to coast, organizations are updating their business continuity processes and disaster recovery plans for COVID’s next wave.

    Software developers and testers are typically perceived as being able to adapt quickly to changes and the fast pace of IT. Since the beginning of the pandemic, SaaS adoption has become a go-to platform for businesses of all sizes looking to ensure business continuity and enable innovation during these uncertain times.

    To meet this demand, developers have worked at ever-increasing speed to configure, test and deploy advanced features and services to their clientele. This quickened pace, for some, has led to the abandonment of proper security guardrails.

    There are a few key ways to mitigate the pressure and risks involved in this accelerated environment, balancing continual innovation with ensuring developers and testers are applying robust security strategies.

    Fail Fast, Succeed Early

    At its core, DevOps is the process of using development technology to solve operational IT problems. Having a well-defined strategy helps; however, it’s nothing without proper implementation and calculated risks. Both of these factors help your organization achieve its goals in a shorter amount of time.

    Here’s an example. One of my colleagues worked on a software development project where, instead of testing one process at a time, they tested 30 different scenarios simultaneously to see which would be the better strategic fit for their organization. They could have planned and tested, one scenario at a time, for six months; however, in three weeks, they could determine their next step in a much shorter amount of time. Methods like this begin with a strong innovation culture where everyone aligns on the same goals.

    Additionally, access to funding also becomes essential, along with the ability to hyperscale. Cost does become a factor; however, this simultaneous testing and fail-fast methodology saves teams an extraordinary amount of time. The goal of failing fast in DevOps is not to increase the chances of failure, but to encourage experimentation, making it a surefire way to bring products to market quicker.

    Put the Cultural Shift into High Gear

    Whether or not a company finds itself in crisis due to the pandemic, leaders need to remember that tools are not the magic bullet of DevOps; culture is. DevOps is not only a philosophy, it’s a mindset that promotes collaboration, culture alignment and lends itself to innovation. Innovation is often a term that scares companies or teams, who may feel it is out of their reach. However, consider this: the very act of innovation involves trying. If you’re not putting yourself in the race, how can you win?

    From ideation to pilot testing, organizations need to understand that they can try something without being “all in.” Innovation is everywhere and within every process. What keeps the culture of innovation alive and well is building an ethos of collaboration; that leads to a team that not only thinks but believes that innovation can happen. Culture becomes everything when your organization starts to look for new and innovative ways to push your business and your clients further, successfully.

    There is an important caveat, though. Often, leaders introduce policies and procedures to their team without providing a long-term vision of the outcome(s). This often leads to long-term adverse effects, simply because the underlying organizational culture is not healthy. Even during a global pandemic, where budgets may be tighter, teams are leaner but innovation is still the goal, there must be vision, transparency and effective communication to allow for proper implementation and execution. All of these components start with culture.

    Scale DevOps Through Automation

    Working on a test automation strategy is the best way to set your organization up for success. Along with culture and collaboration, automation is a key pillar of DevOps. Research shows 60% of occupations have at least 30% of constituent work activities that will be automated by 2030, globally. Historically, teams have been skeptical about automating their work, and push forward with an “I can do it myself” way of thinking and working. COVID-19 created a massive uptick in demand for IT services, and teams’ pressure to perform has also increased.

    For DevOps teams to successfully “scale up” right now, the implementation of continuous automation into the testing process is critical. As with any type of new technology implementation, there are warning signs to consider.

    As wonderful as automation can be, the process often creates a skills gap; however, this does not mean leaders should shy away from the automation process. However, leaders must be aware of this and come up with a strategy to ensure training opportunities are available to close these gaps.

    The pandemic has reinforced how swiftly change happens, and that companies must be flexible and respond quickly just the same. While IT systems are built to extend and adapt, accelerating delivery cannot happen at the expense of business continuity. Pilot testing amid a global pandemic encourages a culture of transparency, collaboration and experimentation that will empower teams to track inefficiencies at an increased rate.