Category: DevOps Practice

  • Crowdtesting: How to Ensure Quality in Disruptive Times

    Crowdtesting: How to Ensure Quality in Disruptive Times

    The practice of crowdtesting has taken on greater importance during the COVID-19 pandemic, for good reason

    Entering 2020, digital transformation projects and initiatives dominated tech spending for most companies. But, between a global pandemic and fiscal uncertainty around the world, spending must be shrinking, right?

    Think again.

    If anything, the pandemic has created a sense of urgency for many companies, accelerating digital transformation in organizations. According to June data from TEKsystems, 56% of digital experience leaders—companies with mature digital transformation strategies—have increased spending on digital transformation. Remarkably, more than one-third of digital experience laggards—those that have historically had limited digital transformation initiatives in place—also increased spending on digital transformation projects.

    The rush can be attributed to COVID-19. For businesses, it has changed the future of work. Distributed workforces are nothing new, but very few companies were prepared to deal with a fully distributed model in which all employees are working remotely. The pandemic has changed buyer behaviors, too. In lieu of malls and brick-and-mortar stores, people have turned to e-commerce sites for the bulk of their shopping. Legacy companies, such as Pepsi, for example, are building direct-to-consumer e-commerce sites in response to the evolving market dynamics.

    Digital is now the primary means of communication for businesses. Digital quality is no longer a niche issue for the application and DevOps teams; it is a strategic business imperative in the C-Suite.

    Apps Everywhere, At All Times

    Apps need to be tested by real users, on every device, network and operating system, across the globe and at all times. The typical workday used to be 9 to 5, but that’s no longer the case. With most workforces now remote, the days are longer and the diversions greater (yes, I’m looking at you, juggling Zoom calls and your daughter’s remote learning plan at school). Customers, too, have higher demands for the technology they use. There can be no downtime; downtime means customers will look for alternatives, becoming ex-customers and resulting in lost revenues.

    In today’s extremely fragmented device landscape, QA teams face increasing difficulties in keeping up with the myriad device/OS combinations they need to test on. For obvious reasons, purchasing and maintaining a nearly endless pool of devices is not an option—not only is it too expensive but it’s also time-consuming and harms the team’s productivity.

    Beyond logistics, QA teams must collect data from real-world testing to make informed decisions. No matter how many test cycles are run, QA teams can’t uncover all unexpected bugs and edge cases unless they include in-the-wild testing in their strategy.

    To test anything related to hardware in an efficient manner, leveraging a community of remote testers is the best way to obtain reliable results without burdening internal QA resources, generating disproportionate costs or missing out on important use cases.

    Crowdtesting Replaces Offshoring as the De Facto Way to Test Software

    With a market greater than $50 billion in India alone, there is no denying the offshoring model worked. But, the pandemic exposed pre-existing cracks in the model, causing many businesses and entire industries to regroup, re-evaluate and find new ways to accomplish tasks that just a few months prior would have been routine.

    When the pandemic hit, the supply chain broke. Testing and product development facilities built on product teams working collaboratively in close proximity struggled to keep up with the most basic needs of their customers. Outsourcing companies and their employees lacked the infrastructure to work remotely, negatively impacting the business continuity of their clients.

    This new reality leaves companies that are used to the offshoring model for testing and QA with one big question: what is the best way to test software and digital experiences in a post-COVID-19 world?

    While crowdtesting has been a factor in application and digital testing for more than a decade, it has taken on increased importance as internal QA teams can no longer maintain business continuity while working remotely and the offshoring model has faltered amid the pandemic.

    The reason the crowdtesting model remains a reliable answer even during COVID-19 is that it is always done remotely, via a community of vetted testers who already work in remote environments. This setup allows testing teams to maintain business continuity, while often improving test coverage across devices, operating systems, geographies, demographics and more.

    As an example, let’s look at how the Israeli government used crowdtesting to bring its tracing app to the country. The Israeli Ministry of Health developed the app using cellular GPS data to provide alerts on areas with high concentrations of COVID-19 infections. The app is designed to prevent COVID-19 spread by notifying people who were in the vicinity of verified coronavirus carriers. Similarly, healthcare provider K Health has used crowdtesting to help it launch a new COVID-19 diagnostic feature. K Health was already using crowdtesting services prior to the onset of the pandemic to ensure its mobile app functioned properly across all relevant device/OS combinations and timezones but found the scalability and reliability of the model meshed perfectly with the demands on healthcare providers in the new normal. When K Health offered free services to all Louisiana residents, crowdtesters were there to scale testing at a moment’s notice and provide 24/7 test coverage for the K Health app.

    It was urgent to get the app out quickly, but it also needed to work properly. Did push notifications go through promptly and to everyone? Would the app work across devices, and in different configurations? Since launching the app in March, the Ministry of Health has been able to leverage continuous crowdtesting to identify dozens of bugs that could have prevented Israelis from using the app or trusting its results.

    For example, the testers discovered that the app crashed when it was used in dark mode, and certain situations led to the app showing that it detected data even when data and location services were off. Since this second error was directly related to the main functionality of the app, it represented a very critical bug for the Ministry of Health to fix.

    Crowdtesting uses real devices and real people in their daily environments, which accounts for all these variables that are not seen in traditional labs and offshoring facilities. That makes crowdtesting a valuable testing approach even after the COVID-19 pandemic and resulting lockdown ends.

  • xMatters Streamlines Incident Management

    xMatters Streamlines Incident Management

    xMatters today announced it has expanded the capabilities of its incident management platform to better address the requirements of more complex IT environments.

    New capabilities include an Incident Console to better visualize and triage incidents, automate responses, improve collaboration and access to richer analytics to optimize response times. Incident metrics are now also automatically collected from integrated systems and surfaced along with the notification to improve resolution times.

    IT teams can also use a Flow Designer tool to automatically keep related systems current with one another, including issue tracking systems, service desks and status pages.

    xMatters CEO Troy McAlpin said the updates are part of an effort to unify IT incident management at a time when the adoption of new applications and systems to enable organizations to have employees working from home has increased.

    A survey of 300 IT leaders and business professionals published today by xMatters revealed nearly three-quarters of respondents (72.3%) now spend at least half of their time resolving incidents, with more than a quarter (27.3%) of those respondents saying they their team spends at least 80% of that time resolving incidents. A total of 43% of respondents said their organization still relies on less sophisticated processes to manage IT incidents, such as alerts, email, paging, conference bridges and physical outreach.

    IT incidents are also starting to have a bigger impact on the business, noted McAlpin. The survey finds 20% of companies with 1,001-5,000 employees are budgeting more than $10 million on digital transformation initiatives. Each IT incident involving those applications now typically involves not just employees but also end customers, he noted.

    As IT becomes more complex, he said, the need to modernize IT environments has become crucial. One of the many reasons IT organizations find it difficult to automate IT management is there are still many unique platforms running isolated applications. IT teams would be well-advised to ask themselves if these unique instances of a platform are truly warranted. If not, that application workload should be retired or shifted to a platform that is more easily automated.

    Longer-term, McAlpin said artificial intelligence (AI) will increasingly be employed across IT operations, otherwise known as AIOps. Those advances won’t replace the need for humans to manage IT, but it will allow IT teams to better automate responses to routine incidents that today require too much time.

    Even as IT becomes more complex, the simple truth is most organizations are not looking to expand the overall size of the IT department. In fact, in the wake of the economic downturn brought on by the COVID-19 pandemic, there are many organizations that need to reduce the size of their IT organizations. Regardless of motivation, there are a host of mind-numbing tasks that IT teams are asked to perform every day that, in keeping with best DevOps practices, should be ruthlessly automated.

  • OutSystems Employs More AI to Accelerate Low-Code Development

    OutSystems Employs More AI to Accelerate Low-Code Development

    OutSystems today at its online NextStep 2020 conference announced it is making more extensive use of artificial intelligence (AI) to accelerate the building and deployment of low-code applications.

    The company unveiled AI Assist to automate, guide and validate processes throughout the application life cycle and Architecture Dashboard, which employs machine-learning algorithms to enable IT teams to visualize complex application architectures.

    OutSystems is also adding Workflow Builder to visually map complex business processes and automatically generate workflow-based applications, and Experience Builder, which enables developers to rapidly prototype mobile applications based on common patterns and flows.

    Finally, OutSystems has added Integration Builder to simplify integration with packaged applications such as those from SAP and Salesforce.

    Mike Hughes, senior director of product marketing for OutSystems, said the AI capabilities being added extend an existing TrueChange capability based on machine learning algorithms that checks for bugs and architecture errors, analyzes the impact of changes to components and application dependencies, provides team and architectural governance and monitors performance in real-time. The goal is to automate as much of the DevOps process as possible on behalf of developers of low-code applications, he said.

    In general, he noted, low-code tools are being embraced by professional developers to accelerate the development of even the most complex applications. In fact, while low-code tools may make it possible for end users to participate in the development process, there are not many so-called citizen developers building low-code applications on their own.

    Adoption of low-code platforms is accelerating at a time when many organizations have increased their reliance of software-as-a-service (SaaS) applications. While each SaaS platform makes available either a low-code or no-code tool for customizing the application environment, Hughes says enterprise IT organizations require tools that enable them to build and deploy custom applications and workflows than span multiple SaaS platforms and on-premises applications. That issue becomes especially apparent to any organization looking to accelerate digital business transformation initiatives in the wake of the COVID-19 pandemic, added Hughes.

    In fact, he noted, the one thing the pandemic has reminded everyone is that change is the only constant. IT organizations need flexible application development and deployment tools more than ever.

    Of course, there’s no shortage of options when it comes to low-code and no-code tools. In fact, Hughes said the distinction between these tools is starting to blur as platforms such as OutSystems make different capabilities available to different classes of developers depending on the use case.

    In the meantime, as the number of low-code applications that are being developed continues to increase, organizations should make sure they have the DevOps processes in place needed to deploy and update these applications more frequently. After all, it doesn’t take long for a backlog of low-code applications waiting to be deployed by an IT team to build.

  • Oracle Proposes Replacing Mercurial SCM for Java With Git

    Oracle Proposes Replacing Mercurial SCM for Java With Git

    Oracle today at its Oracle Developer Live—Java event proposed making a bevy of updates to Java that includes replacing the Mercurial source code management (SCM) platform, which is the repository Oracle created to share updates to the Java community, with Git starting with the initial availability of Java 16 and then migrating the project itself to GitHub.

    In addition, Oracle has developed server-side tooling compatible with GitHub and GitLab and client-side tooling compatible with Git and Mercurial to aid in the migration. The effort is based on the Project Skara initiative, which already provides read-only Git mirrors of all active and consolidated lines of development for the Mercurial SCM repository.

    Oracle is also proposing to add a Vector application programming interface (API), along with enabling some C++ features in Java 16.

    Oracle today also announced enhancements to Java 15, including support for Edwards-Curve Digital Signature Algorithm, hidden classes and reimplementing the legacy Datagram Socket application programming interface (API). In addition, support for a more advanced garbage collection tool as well as text blocks has been finalized.

    Other capabilities that have been advanced but are not finalized in Java 15 includes support for sealed classes, enhanced pattern matching, records and an API for accessing foreign memory.

    Chad Arimura, vice president of Java developer relations, said collectively the latest innovations show the venerable programming language is still vibrant. Despite a plethora of options most enterprise IT organizations still rely mainly on Java to build applications even as they transition to building microservices-based applications based on containers deployed on Kubernetes clusters. As such, Java is not in danger of suffering the same fate as the COBOL programming environment, which from a pace of innovation has grown comparatively stale, noted Arimura.

    Many of those organizations are also well down the path toward adopting best DevOps practices that revolve around a Git repository. Adoption of Git as the SCM repository for the Java project will further those efforts by simplifying workflows for organizations that have standardized on Git repositories, he said.

    While Java continues to dominate development of applications in the enterprise, it’s also true organizations of all sizes are employing a wider range of programming tools. By embracing Git and GitHub, the Java community will be able to more fluidly coexist with a wide range of open source projects being created using a diverse range of programming tools. Enterprise developers are clearly still relying on Java to write most of their server-side applications, but more client-side code is being developed using frameworks based on, for example, JavaScript.

    In the meantime, however, IT organizations looking to modernize application portfolios should be able to count on the fact that nearly 30 years after its initial launch, Java remains relevant. The challenge now is determining where best to rely on Java alongside a plethora of other programming tools that developers of all ages now regularly employ.

  • TechStrong TV: The Low-Code Movement, With ServiceNow

    TechStrong TV: The Low-Code Movement, With ServiceNow

    ServiceNow is well-known for its IT transformation products and customer/employee workflows. But the company has another technology, App Engine, a low-code application platform that lets people build applications faster than they can on any other platform.

    In this TechStrong TV interview, I speak with Josh Kahn, general manager of the platform business unit at ServiceNow, about App Engine and the evolving low-code landscape, which is a very hot topic in today’s business environment. The video is below followed by a transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us on another episode of TechStrong TV here on Digital Anarchist. Really happy to be joined for this episode by Josh Kahn. Josh is the general manager of the platform business unit over at ServiceNow. Hey, Josh, welcome.

    John Kahn: Alan, thank you for having me. Really excited to be here today.

    Shimel: We’re excited to have you here, man. Let me just make sure I didn’t mess up anything with the title or the unit and everything, right?

    Kahn: Got it exactly right. That’s right.

    Shimel: Cool, man. Appreciate it. So Josh, look, our audience doesn’t really need an introduction to ServiceNow the company. You know, it’s probably one of the most successful companies over the last two/three years in the tech universe, if you will, right? Phenomenal growth, phenomenal story. But you’re the GM for the platform business unit, and I don’t know if our audience is as familiar with that. I think a lot of people think of ServiceNow with ITSM and those kinds of things. What exactly is the platform unit there?

    Kahn: Yeah, so the platform business unit actually has two parts to it. One is taking requirements from all of our different lines of business and defining shared capabilities in the platform itself that they use to build their products. The other part is defining the things that our customers and partners need to build their own applications on our platform just like we do. And the platform at ServiceNow really is a single platform. It’s one platform, one architecture, one data model. So we make sure that the same capabilities our own businesses have to build on are available to our customers and partners. It’s the job me and my team have to make sure that that’s world class for all of the developers out there in our customers and our partners and in the ecosystem

    Shimel: Sure. Excellent, man. Josh, if you can, share with our audience a little bit, what’s your background

    Kahn: Yeah, so I’ve been in platforms for a long time. I actually graduated college and my first job was at Accenture where they said, “Hey, you’ve got to do some development work before you can get on to being a business analyst.” And I thought, oh man, I can’t wait to be a business analyst. I’ll power through this development stuff, and I just loved it, and I spent the first years of my career programming and programming in C on Windows 3.1 and doing three-tier client server systems. That was a lot of fun. At some point, the internet came along and I realized, wow, that was a much better architecture so found my way to Netscape.

    Shimel: A little bit

    Kahn: Say again.

    Shimel: I said a little bit better.

    Kahn: Yeah. So I found my way to Netscape which was the only internet company at the time and ended up there working on the Netscape 1 platform in a product management role and just http: my career continued to focus on development environments, platforms, and helping people bring solutions to market. Fortunately, I’ve been at ServiceNow for about four years and am continuing to really focus on how do we build a platform that lets our customers unleash the innovation in their organizations and create the kinds of applications that we create ourselves today? We want to bring that to our customers. That’s a really fun job to have.

    Shimel: Excellent. You know, it’s funny. About two weeks ago I interviewed Tom Jermoluk. He was at Netscape obviously with Jim Clark, and he went off with Jim on a bunch of other adventures. They’re still adventuring, right? Tom is now at Beyond Identity or something like that. But yeah, we were talking about – I mean those Netscape days, you’re of an age, I was an OS/2 guy rather than Windows 3.1, truth be told. But you know, you’re at an age where Netscape, people forget I mean that was the opening of the internet commercially, right, without Netscape and what went on there. It was crazy times. Unbelievable times.

    Kahn: I mean the thing that I was building an application where we designed a billing system for an airline to bill back and forth and exchange services and fees and they just sort of wash out dollars at the end of the month and somebody wrote somebody else a check. You know, one airline painted the other airlines planes and then the other airline de-iced. It was a really complicated data model to build, and we had to roll it out to all these different hubs but we tackled the data model problem. We tackled the logic problem. The thing that we couldn’t get around was the messaging infrastructure. That’s the thing that the internet made so easy. I mean among many things, I think it’s one of the reasons that it’s unlocked so much potential is it’s so easy to get a message from point to point for an application.

    Shimel: Absolutely.

    Kahn: It’s really, really changed the –

    Shimel: Yeah, no, it was revolutionary. But you know, you bring up a good example and that is kind of what development was like back then versus what development can be like today. That kind of brings me up to App Engine and what I wanted to speak to you a little bit today, right, where, look, man, it’s – thank God you don’t have to do what you were doing in 1996/97/98 to develop an application today, right? We do have the internet. It does make a lot of things easier.

    But we also live in a time of low-code no-code revolution where you don’t have to be a C-plus developer anymore to put together an application rather quickly. Rapid application development, right? And so I think a lot of people who are familiar with ServiceNow, Josh, they may not be familiar with App Engine and what it brings. So talk to us a little bit about – if you don’t mind, talk to us a little bit about App Engine.

    Kahn: I’d love to, and I think you’re absolutely right. We’re well-known for our IT transformation products, customer workflows, employee workflows, less known for App Engine. So we focused App Engine on providing an application platform that lets people build applications faster than they can on any other platform. A lot of the first questions I get from customers is, “Hey, I have a number of application platforms and I can build – yeah, I want to go faster but what kinds of applications is your platform really best for?”

    And one of the things that we’ve really done, in addition to making it possible to build low-code and build fast, is focus on digital workflows. So digital workflows are ways to drive business process across the organization. A lot of organizations were building those pre-COVID because they had digital transformation initiatives, but the COVID pandemic put the speed and the need of digitizing business process to the forefront of every organization, every government. It’s really just been a catalyst for building applications that drive business process, run across a lot of different systems, and create those sort of digital outcomes.

    Shimel: Great. You’re preaching to the choir here, and we see it every day. Six years’ worth of digital transformation in about four months. That being said, digital transformation is way big, right? I probably went out of the screen on that. I apologize. It’s very big. But low-code no-code allows us to almost take it in bite-sized chunks. It allows us to get our hands around it without the huge development teams and all the languages and all that and really – especially like now in COVID, right, I need an application that does this now, right? We just sent everyone home remote. I need to be able to do this now. And so things like App Engine enable that sort of thing. Do you have any maybe examples you could share with us?

    Kahn: Absolutely. Yeah. I think you’re absolutely right. And we see a world where, look, people who write software and people who code are still going to be incredibly important, right?

    Shimel: No doubt.

    Kahn: The issue is demand. There’s just too many applications to build so we’ve got to help people who don’t know how to code but do know business process to create those applications. That’s what we really tried to do with our low-code platform. And I’ll give you some examples, and a lot of the kinds of applications that people build in a no-code way tend to be the simpler variety of applications. So a few that we’ve worked with customers on. One they call Opendoor. So this allows all of their employees to submit ideas or concerns to the executive team. It was an idea at this organization that started when it was a very small company.

    As the company has grown and grown, it’s no longer feasible for people to walk into the CEO’s office and he was getting 60,000 e-mails a year with ideas for how to do things better or how to mitigate risk. And so they had someone build an application using low-code technology called Opendoor, and any employee can go on a mobile device, submit an idea or a concern and it gets routed to the right executive team in the corporation at the executive level to address so it doesn’t all go to the CEO. If it’s obviously an issue that should be thought of in the finance department, it goes straight to the CFO. If it’s something that should be thought of in the human resources department, it goes straight to the talent officer. But it’s a way that employees are able to get those requests, visibility to the executive team. It was built without developers writing code. It was simply a no-code application process.

    Shimel: Excellent.

    Kahn: You know, I think there’s also an interesting dynamic, too, where we see an opportunity for people who write code to support those – we call those citizen developers. A lot of people use that term citizen developer. So what we think of as a citizen developer is someone who is technical but doesn’t typically write code. So I’ll give you an example. One individual was the person in her department that they would always go to and say, “Hey, we’re going to evaluate a SAS application for project management. Can you go look at these three apps and tell us which one you think is best?” So she really knew technology. She could log in, find her way around, configure things but wasn’t going to go write code to build an application herself.

    What we’ve seen with the citizen developers is they can get pretty far into building an application, but oftentimes they hit a cliff where they need help from somebody who can really write code, whether it’s an integration with a system of record or some kind of complex business logic that’s just a little bit beyond the capabilities of the no-code tooling that they’re using. That’s where we think it’s really important to bring these citizen developers and the developers who write code together on a single platform so that they can support each other and we can get scale from the citizen developers but also have the pro code developers do the tough stuff that really empowers and enables the citizen developers.

    Shimel: You know, Josh, that is so dead on to part of what DevOps is about, right, which is all of us working together in that thing. I wanted to let you finish your thought, but a couple of comments on it is number one, when we look at the full spectrum of the kind of applications modern enterprises, modern organizations need to function, yeah, there are some things that are really hard. They need applications that are really hard to build, have very, very complex workflows and very complex needs or requirements. You really do need to be a high-level developer, let’s call it, a really high level experienced developer to pull that off.

    But I would venture to say that that’s probably 20 percent or less of the kind of apps – when you look at the full spectrum of apps that people use, it’s probably 20 percent or less. I think the majority of the apps are rather mundane, right? They don’t need the rocket scientist to develop. If you just give someone some good building block tools, they could put together 90 percent of the functionality they need, 95 percent of the functionality that app needs to be functional and effective.

    And I think, you know, we said it before, there’s something like 40 million, 42 million developers in the world was the last number I saw, growing 20 percent a year. Would be the fastest growing country on Earth. It’s still not enough. As you said, there’s still not enough developers. So part of what we have to do in DevOps, part of what we do in digital transformation is say, “Hey, if we don’t need one of those 42 million on this but we have someone here doing it, let someone here do it.” We don’t need that pro developer, if we can call it that, to do everything every time. And so the citizen developer as the term is coined, right, becomes more and more important to do more and more of these 80 percent or so apps that don’t require it, right, that don’t require that pro guy or pro gal.

    And so the real question for organizations, and I’m sure this is something you deal with, is how do you empower those people? With an App Engine maybe. But sometimes – Josh, again I’d like to hear your voice – it’s not just the tool. It’s making the CIO, the IT department aware that, hey, let’s not just dump everything on that developer’s desk because he is dealing with security and DevOps and testing and deployment. He’s got enough on his plate. Are there things we can take off the plate for the citizen developer and get it done quicker, cheaper, and just as functional?

    Kahn: Yep, absolutely. So it’s really interesting you say that because we see a pretty common journey with a lot of our customers that have great success with App Engine and it tends to start with the team building a business-critical application of some sort. So I’ll give you an example. Academy Mortgages is one of our customers, and I talked for a bit with the CIO about their journey, and I’ll describe it in terms of what Academy Mortgage did, but this is a very common journey that plays out in lots of our customers.

    So Felix was describing first they had a couple of business-critical applications they built out on the platform. So Academy Mortgage does loan origination. Then a lot of times they will package them up and sell them to investors. So there’s a process when you sell them where there’s a set of stipulations that have to be attested to as a part of that process. So they had a hundred people that manage that stipulation process.

    So they built a digital workflow on our platform with App Engine, and they were able to do that process with half the number of people. So they reduced from 100 people to 50 people to process even more loans than they had in the past. You say, well, hey, where did those 50 people go? And I asked Felix that question. He’s like, “Hey, these are people that know the mortgage industry. They’re incredibly knowledgeable. They’re great employees. We redirected them to other work.”

    So this is a case where they took a business-critical application, had a huge cost savings and increase in revenue generation for the organization through the combination of saving those people and redirecting. But that was only step one. You know, the next thing is they built a small center of excellence. So they put, not huge, three people in a team that were like the experts on building App Engine applications. That team was able to build over 50 applications for 27 different departments at their organization. So now they’ve gone from a couple of big wins – I mentioned one of them, but they had a couple of big wins – to a small center of excellence team and then they move on to phase three.

    Once they’ve had that broad sort of impact with the 50 applications, they start empowering the rest of the organization to build the simple ones, right? So Felix calls it power to the people. He wants to let the citizen developers do the really simple stuff and his CEO team is gonna continue to do the high impact, high complexity, real business value-driving applications. So the vision that you laid out, Alan, is exactly what I’m seeing our customers doing is combining both professional developers for the really complex stuff and citizen developers for the simpler applications

    Shimel: I mean it’s the right person for the right job using the right tool, quite frankly. So you know, Josh, I, like the rest of the world, hope and pray that this COVID thing doesn’t stick with us forever and we come out the other side somehow into what the new normal is. In this new normal, what role – I mean do we go back – we can’t go back to the way it was before, but what role does low-code no-code play in this whole thing going in this new normal that emerges

    Kahn: Yeah, I mean it’s incredible the amount of processes that are being re-engineered across every industry. Anything that depended on contact, human contact, paper changing hands, two people being in the same place is now being re-engineered to become contactless processes. And so for any organization will have hundreds or thousands of those processes, and to think that you’re going to need a skilled developer to write code to reengineer each one of those processes is – you know, you’re going to put the timeline out too far for your organization to be successful. You’ll put people’s lives at risk. You’ll put your organization at risk.

    And so the pace of digitization is just going through the roof. The only way to really keep pace with that digitalization is to empower citizen developers. So what we’ve seen in our customers is a real demand to empower their citizen developers, their business analysts to reengineer business process. They know that process well. If they can be armed with tools that allow them to model it, define it, and deploy it, then the organization can create transformation at scale. That is what everyone is looking for in this post-COVID era.

    Shimel: Absolutely.

    Kahn: We’re dealing with it today, but even as we move out those processes will continue to be reengineered and change.

    Shimel: Agreed. I think, look, the whole thing around business process automation, robotic process automation, RPA, another popular topic and I think the other thing is we’re interviewing a analyst a couple weeks ago and they said something like we’ve done six months or six years of digital transformation in a couple of months.

    The interesting thing about that is it’s almost like putting money in the bank. So that money’s there now. So when and if this COVID enters, you don’t start with zero in the bank. You start with what you’ve already deposited, right, and then we build on that. I think that’s an important thing for people to remember in that all of these investments we’re making now and empowering our citizen developers with tools like App Engine. They’re now short term or diminishing assets. These are long-term investments we’re making that will serve us well going out beyond the immediate crises or whatever you want to call it.

    And it’ll be interesting because I feel like, you know, so like you, we both came of an age, right, when the internet came onboard and we had this concept of internet time, right, this kind of crunch time. In internet time, it goes three times faster than the real world. I think we have now introduced like COVID time, and I don’t mean to be – look, a lot of people are suffering. A lot of people are dying. But we have compressed timeframes in terms of how fast we’re developing apps, in terms of how fast we are bringing onboard these things. I don’t think that goes away. You can’t put that genie back in the bottle.

    Kahn: You can’t. You know, I think there’s a perfect example of that that we saw with the City of Los Angeles. So the mayor’s office wanted – this is early on in the pandemic. They wanted to roll out COVID testing for all of the citizens of Los Angeles, and they called ServiceNow, and we brought in one of our partners on a Saturday morning. The mayor was saying I have a press release on Sunday night. I need to roll out the testing application so that when we tell people there’s testing, we can tell them where to go to sign up. And so this partner, Cask was our partner that did this, they assigned six developers who worked through the night, did a demo for the mayor’s office on Sunday morning, and by Sunday evening they had this application up and running for 4 million citizens of Los Angeles, eventually expanded to the county so you get to 16 million people.

    But it’s interesting because it wasn’t a registration form. It was a really powerful logistics app. Behind the scenes, they had to have agents who could route the request to the right site to get tested. They had different sites and each site had two-hour windows where they didn’t want to put too many people in a window because then you have –

    Shimel: Unbelievable.

    Kahn: – too close together. So you want to talk COVID time, I mean within 48 hours they were able to build an application that handled a complex logistical challenge and make it available for 4 million people. You know what I mean? Even on the internet.

    Shimel: Fantastic.

    Kahn: – that would be inconceivable.

    Shimel: Crazy. I don’t want to get into politics, but why couldn’t we do that nationally, man? You know, if it worked for L.A. for a couple of million? But let’s not go there. Josh, we’re about out of time. I want to thank you for coming on and sharing a little bit with us, talking, learning. You know what we didn’t mention? For people who want to find out more about App Engine, where can they go.

    Kahn: Yeah, look, best place to go is ServiceNow.com. You’ll drill into the platform area, learn about App Engine. If you’re interested, you get your own developer instance and you can be up and running building applications in no time.

    Shimel: Fantastic, man. Hey, thanks for joining us. Josh Kahn, VP of the Platform Business Unit at ServiceNow, talking to us about App Engine, empowering citizen developers around the world. This is Alan Shimel for TechStrong TV. We’ll be right back with our next guest.

  • How Centralized Log Management Can Save Your Company

    How Centralized Log Management Can Save Your Company

    Through centralized log management, organizations can consolidate all log data into one central, data highway and directs logs wherever they need to go

    The digital transformation wasn’t gradual. It came crashing into industries worldwide in response to safety restrictions around the pandemic.

    Nearly a third of Americans are working remotely in light of the pandemic—drastically increasing the external users—with no signs that employees will be returning to the office full-time post-COVID-19. A recent PwC survey found that 83% of employees want to work remotely at least once a week and that 55% of employers anticipate their employees will do so even after the pandemic.

    Companies have implemented new and creative solutions to deal with the spike in remote access: VPNs and SSL connections through web applications, to name a few. However, many of these solutions were only a bandage that won’t suffice for long term remote access.

    There is one thing amid all these changes that can become an increasingly large problem if left unaddressed: logs. Logs are collections of data that continue to be collected whether users are in the office or in their living room. Without centralized log management, this data can put organizations at a critical security risk. As the digital transformation takes industries by storm, it’s important for organizations to remember the importance of managing logs.

    Today’s Log Landscape

    When a company’s remote workforce jumps from 50 to 5,000 in a matter of weeks, things change. Compared to in the office, logs at these companies have jumped by 10,000%. Remote work generates logs on security access points, remote access, server logs, terminal services and application logging—all of which are fed into an organization’s security information and event management solution (SIEM).

    This jump is creating and revealing more blind spots to companies, which proves how difficult it is for administrators to increase the rates for their security monitoring tools to reach that level without drastically upping their company’s budget for its SIEM. Even Microsoft and network providers are running into issues with so many changes happening at the same time. Additionally, companies have to worry about privacy laws, making sure all personal data is encrypted and secured.

    Centralized Log Management

    Organizations should implement centralized log management (CLM) to consolidate all log data into one central, data highway that collects all logs and directs them wherever they need to go. CLM solutions reduce SIEM costs once SIEMs are no longer effective log management tools.

    Dropping all logs into a SIEM spikes costs, so oftentimes only a portion is collected, which creates fragmented or incomplete pictures and impacts security monitoring and incident response. CLMs lift the burden of having to hire staff, provide training and support for SIEMs. CLMs also reduce the costs organizations would incur with their SIEM providers, as well as the risk of endangering the SIEM infrastructure by storing unmanaged logs.

    Fragmented data collection can become a unified data collection with a data highway. Organizations can now filter unruly data and deliver only what you need. This helps overcome the age-old strategy of letting separate teams have their own sources of data, which could instead be directed to the appropriate team via your data highway. The data highway lets you collect once and use it many times, where it’s needed.

    Parsing: Cleaning up the Data

    Once logged, data needs to be parsed. To prime your data to be parsed for specific items, unnecessary and unwanted information must be filtered out. This diminishes the storage space logs take up and increases the usability of the data.

    One example of superfluous information is the timed mark that many applications add into the log of their system to show they are online. Unless a security auditor will need to see this, there is no reason why an organization should be paying to store it in their SIEM. Administrators are even able to filter out all extraneous text and add parsing for specific events. This quickly and easily reduces costs that are likely spiraling out of control during this time.

    Parsing, filtering, masking and other transformation techniques in your data highway allow security teams to overcome privacy issues and filter out personal information that shouldn’t be distributed. Resolving this problem could become crucial as more and more personal data is being collected than ever before, and as privacy laws are becoming stricter.

    The Data Highway

    Build your dream team to utilize your new data highway to its greatest potential. Not everyone reviewing logs will be SIEM experts or as skilled as a Linux or UNIX administrator (or even one at all). Build your team to be able to easily operate your new data highway, because you don’t want it to be gathering dust on the shelf.

    With your new data highway, you’ll be able to optimize your SIEM, increase your likelihood of meeting compliance requirements and be able to log from more places with easy searchability. With that encrypted data store, your compliance officer may even be able to sleep at night. Beyond the SIEM, you’ll be able to send your data anywhere: Kafka, MongoDB, any database, big data systems and more.  Don’t just optimize your SIEM; build your data highway and collect those logs once, distribute them where they need to go and cut costs with centralized log management.

    So, in this crush of new technologies spiraling into the new digital transformation age, don’t forget the importance of managing your logs. IT and security admins shouldn’t be in the position of going to company management to inform them of uncontrolled SIEM costs. They can be managed and reduced without losing their effectiveness by simply feeding to the SIEM only the data that needs to be there.

  • Onboarding Is Science, Not Art

    Onboarding Is Science, Not Art

    Make sure your new team members are getting a well-rounded onboarding

    In Fortnite: Save the World, there is a questline in which a character named The Cloaked Star answers, “Figure it out yourself,” to a variety of questions from a new hero who was a DBA before the end of the world came. It is hilarious because, at that point in the story, the new hero doesn’t have the information to do so.

    Most of us have onboarding of new DevOps employees so simplified it would make us from five years ago cry tears of joy. Give them a container or virtual that is already equipped the way they need and they are ready to be productive, right?

    Welllll … kind of. Let’s stay totally stoked by the idea that pre-made tooling that will run fine on whatever they’re running it on is a huge step, then acknowledge that in the age of DevOps, tribal knowledge is still very much a thing. There is this other repository we hit for X, an alternate API for Y, that system that does not work the way one expects, and so on.

    We need to apply the same science to knowledge transfer that we do to tooling. It is not all self-documenting, it is not all obvious, and that knowledge absolutely needs to be transferred to new employees.

    Some of us have this down pretty well. Far too many of us do not.

    Two solid ways to transfer knowledge are documentation that is both thorough and up to date, and a buddy system. Both have strengths and weaknesses, but both address the parts that are not automated. If you go with documentation, make certain someone is responsible for keeping it up to date in the fast-paced world we find ourselves in. If you adopt the buddy system, make certain your team knows what information is most important to impart. While each buddy will be asked questions, it is the things that might surprise new employees that buddies should be prepared to impart.

    You are building the future “legacy code.” How far in the future that is remains to be seen, but given our rate of change, probably sooner than you think. Even if you use the buddy system, there needs to be some level of documentation included. The number of projects that use something like “Joe’s database designed in his basement” because it had the best caching available but then employee turnover removed everyone with any knowledge of the weak spots in the chosen product, is stunning.

    So make sure your new team members are getting a well-rounded onboarding. Make certain they have the info they need to be productive and avoid pitfalls that your team has already identified. Make their transition easier, and they’ll be productive sooner. And hey, you might avoid that big bug caused by someone’s lack of information.

    Whatever you do, no matter their level, make sure they know the important bits. And keep kicking rear, now with new team members, equipped to help you along.

    And don’t be The Cloaked Star. Help a new employee out.

  • 3 Ways To Tackle the Operations Complexity of DevOps

    3 Ways To Tackle the Operations Complexity of DevOps

    DevOps is challenging, some of its complexity requires a platform that is both SaaS and managed environments, running on top of several cloud providers and potentially on-premises as well. Is there a platform that connects applications and systems while supporting enterprises as they accelerate their digital transformation efforts? If done the traditional way, you have all the ingredients to fall into an operations nightmare. Unless you tackle the challenges with cloud-native approach from day one.

    Let’s explore three ways to tackle the operations complexity of DevOps.

    Cloud-Native Architecture

    Why use Kubernetes? This technology is an open source system for automating deployment, dealing with massive scale and management of containerized applications. If the main initiative is to isolate every single integration that runs, then select an architecture component that could give you a head start.

    A well-designed application based on microservices and running on containers can benefit heavily from technology such as Kubernetes in the following ways:

    • Resilience & Fault Tolerance: These are key ingredients for today’s highly available, always-on systems. With the help of Liveness and Readiness probes, we can set up an environment where any misbehaving container could be automatically recycled and have a new instance ready to use.
    • Multizone Cluster: With a multizone cluster, it is possible to apply hard-to-achieve fault-tolerant architectures where a container running on a zone is automatically moved to another zone if there is a failure. By coupling that with GCP’s ability to replicate volumes across zones and you can deliver a true fault-tolerant architecture.
    • Millisecond recovery: Any restarted container takes milliseconds to get ready again, so absolutely no interruption occurs.
    • Microservice Isolation: Misbehaving containers won’t affect others as there are reinforced limits in terms of CPU and Memory usage.

    Deployment as Code

    GitOps is our mantra. GitOps is a way of implementing continuous deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and continuous deployment tools.

    The technique here is to follow regular Git Flow methodology and have automated “operators” apply changes to a Kubernetes cluster. These operators are regular containers running on a Kubernetes cluster, which constantly monitor Git source repositories for changes. Once a change is detected, the operators automatically trigger an update.

    For the automated installations, use Helm as the deployment engine. When changes are committed to the Helm configuration in Git, the operators automatically apply those changes.

    This approach essentially reverts the classical imperative deployment model where actions are performed in the environment to a declarative approach where the state of the environment is defined by a set of rules and kept in sync by these operators.

    Outstanding levels of governance can also be achieved in all clusters from a single source of truth. If a manual change was introduced in any of the environments, the operator would detect and revert back to the defined state.

    Normalize Hybrid Environments

    Kubernetes is powerful, but comes at a price. It is very challenging to maintain different versions and distributions, especially when using different cloud providers and on-premises environments. Due to that fact, you must identify a technology that would abstract the complexity away, normalizing the operation.

    Consider Google Anthos for this, which is a full Kubernetes distribution based on Google Kubernetes Engine and is available to Google Cloud Platform customers. Over the years, Google refined its Kubernetes distribution and eventually released it as a product in its cloud platform.

    Main advantages of using a technology such as Anthos include:

    • Standard Kubernetes installation for on-premises, VMware-based environments.
    • Connectors for Kubernetes Engines in AWS and Azure cloud providers.
    • Built-in configuration management capabilities allowing us to declare our clusters and keep them in-sync.
    • Remote-controlled Kubernetes environments from a single admin portal so all cluster resources are easily accessible.
    • Monitoring metrics consolidated on Google’s StackDriver.

    The three ways are more than enough to achieve greater scalability, governance and control of hybrid environments to address DevOps and complexity. They are actually a new mindset for application design and operations. I truly believe that they can help companies deliver better software while recognizing the complexity and challenges of dealing with enterprise applications.

  • JAMstack Boards the Enterprise

    JAMstack Boards the Enterprise

    Set course for development via JavaScript, APIs and Markup. Engage.

    In recent years, the JAMstack web development trend has garnered interest among front-end web designers. A 2020 study by Netlify found 1 in 3 sites serving a million users use JAMstack.

    JAMstack has been viewed as a development style for blogs and startups, but lately, some proponents believe it’s time for enterprise adoption. So, what benefits could JAMstack and serverless offer enterprise architecture? I recently talked with Ryan Coleman, vice president of engineering and product at Stackery, to find out.

    Defining JAMstack

    First off, what is JAMstack? JAM stands for JavaScript, APIs and Markup. It’s is a new(ish) style for building websites and applications based on modern tools and serverless web architectures. We’ve seen its adoption grow exponentially within the last five years or so.

    As defined at jamstack.org, JAMstack enables fast and secure sites that pre-render files directly from a CDN. This avoids tight-coupling between the client and the server, also known as headless. Applied in the right context, it can bring performance, security, scalability and developer experience benefits.

    Admittedly, there is some variation on implementation of this style—PayPal’s Jamund Ferguson simply calls them static apps—but, “the thing that they all have in common is that they don’t depend on a web server,” noted jamstack.org. Jekyll, Hugo, Nuxt, Next and Gatsby are among many JAMstack frameworks and static site generators, and many adopters are listed here.

    JAMstack Benefits

    No longer are IT teams operating a web farm. Rather, they are shifting the process of interacting with live web servers left. According to Coleman, JAMstack is more aligned with these modern practices across the board. Therefore, he sees many potential benefits for its use within enterprise environments.

    Serverless

    With JAMstack, web pages are built during the build process attached to a CDN pipeline. “Instead of running a server farm, you are externalizing it,” notes Coleman. “It’s the CDN’s problem.”

    JAMstack plays nicely with a serverless mentality. “JAMstack helps rethink what production footprint actually looks like,” Coleman said. By reducing your active server footprint, serverless implementations decrease infrastructure costs.

    Security

    With the proliferation of web vulnerabilities, companies are seeking new ways to limit their exposure and avoid catastrophic breaches. JAMstack can help enterprises keep pace, offering a “much tighter place to apply security controls,” he said.

    It allows teams to think of their security infrastructure in smaller pieces, which affords better control and scalability for things such as authorization. “Serverless architecture helps enable enterprise-grade SAML-based Auth tied into your stack,” Coleman noted.

    Democratization Effect

    Coleman also sees opportunities for small teams to disrupt the dominant players by utilizing it. “Companies need to move quickly, achieve enterprise-grade architecture and secure products with less investment on the onset,” he said. These abilities could, for example, enable a FinTech startup to compete on the same playing field as an established bank.

    “How do you create an architecture that is living, and how do you make sure it is as secure and clean as possible?” he asked. “How do you get a whole team together where actually doesn’t have to use 1,000 lines of YAML, and how do we continue to maintain?”

    Since JAMstack adopts APIs, companies could rapidly stitch together high-performing applications. Furthermore, by pairing low-code tooling and JAMstack, teams could drag-and-drop snippets of AWS-managed services to construct web applications very quickly.

    Bi-Directional Interactivity

    JAMstack has a reputation for creating compelling user-facing apps. Yet, Coleman acknowledged a common misconception: JAMstack is static and, therefore, not for enterprise.

    However, JAMstack can be more than a static app; the structure can support secure interactive capabilities. By taking CDNs and buckets and utilizing API connections to rich features such as AWS managed services, it can essentially reach the same enterprise-grade capabilities as other development styles, he said.

    JAMstack: No Longer Only for Blogs

    “Serverless + JAMstack is where web app architectures are going,” Coleman wrote in a recent blog post. Though many view it as a static app, there is growing potential for using this development approach to enable applications with dynamic interactivity. “With AWS in the backend, you can create an interactive enterprise-grade app.”

    Another benefit of JAMstack is the decoupled nature between client and server. This abstraction layer makes for building web applications across multi-cloud arrangements. And as web APIs become more accessible through low-code, the entry barrier to connecting to a MySQL or Postgres database—or handling identity management, for instance—is lowering.

    Once only viewed as good for blogs, JAMstack is gaining more credibility within enterprise architecture as APIs and serverless become more commonplace, offering the potential to increase performance, increase rapid web application delivery and solve other concerns within enterprise situations.

    Coleman described JAMstack as enabling developers to “build that web application the way you want.” How, then, do you want to build?

  • Why It’s Time to Migrate Away From COBOL

    Why It’s Time to Migrate Away From COBOL

    Every few years an alarm goes up about the shortage of COBOL programmers, and then it dies down. While it’s hard to tell whether this cycle occurs because programmers are found or because other solutions are identified, the latest resurgence of interest is at least in part due to the pandemic and state governments’ use of software for social services that couldn’t stand the increased caseload of tens of millions of unemployment claims.

    As we continue to sit in the midst of the pandemic, organizations are thinking about the many ways businesses will have to change. For instance, will cash still be used in five years or will the business need to support some kind of cryptocurrency? It’s time to ask those big questions now—and determine whether it’s possible to make changes without touching COBOL code.

    For most organizations, I believe that in answering these questions they’ll find that it’s time to start migrating away from COBOL.

    The Rise (and Fall) of COBOL

    COBOL is one of the earliest programming languages. It was invented in 1960 and rose to prominence as a language that required minimal programming skills. Part of COBOL’s initial attraction was that it was a domain-specific language designed for business—not only was it easy for programmers to learn, it also could be understood by executives; hence, the acronym for “Common Business-Oriented Language.”

    COBOL was also one of the few programming languages that understood the requirements of business computing—most simply, the fact that an amount like 10 cents can’t be represented accurately in binary was a huge challenge. If you’re a bank, small rounding errors on each transaction add up. Libraries for business arithmetic could be written in other languages, but they’re scarce and hard to find.

    While COBOL never disappeared, its influence faded in the 1980s but many large institutions failed to transition away from it. Today, there are billions of lines of code in governments, banks, enterprises and elsewhere performing essential business functions with few programmers able to maintain them.

    Part of the reason why COBOL fell out of fashion was its inability to adopt things such as modularity or breaking down problems into smaller, functional pieces. When COBOL was invented, old business software was monolithic—and monolithic in a very deep sense. Internally, the software wasn’t partitioned into separate components that could be updated without affecting each other. It also tended to model forms that humans would fill out and couldn’t be submitted until the form was complete. Putting a web interface in front of those monoliths leads to a predictable result: long, complex forms that can take hours to fill out and are close to unusable on the modern web.

    While the COBOL language itself has evolved over the years (with revisions released in 1961, 1974 and 1985 and object-oriented COBOL released in 2002), you still have to ask: what will it take to bring a COBOL program written in the 1970s or 1980s up to date? Is redesigning a program to take advantage of COBOL 2014 any easier than porting it to Java or Python or Go or Rust? Furthermore, COBOL looks unfamiliar and forbidding to most modern programmers, which likely caused it to lose popularity in the first place.

    Finding an Alternative

    So, where are we now, with our billions of lines of COBOL running the world’s governments and finances? We certainly need more people who know and understand COBOL programs. There’s a lot of old code that needs to be maintained, pure and simple.

    But it goes deeper than that. COBOL is just another programming language; if we’re going to maintain (or replace) that software, we need programmers who understand the engineering decisions that made the software what it is. Programmers used a lot of tricks to work around the limitations of 1960s computers. Those tricks just don’t make sense to modern programmers; they solve problems we no longer have. We also need engineers and managers who are willing to look at our current situation—for example, the huge surge in unemployment applications—and think beyond the short-term solution. What does it take to reinvent current systems rather than replacing them? How can these systems become more human-centric? Can they be redesigned to match the way we live and work now? Putting a web front-end on a monolithic business process from the 1950s is the road to failure.

    The new generation of programmers must understand financial programming and how to design business systems. There’s little value in migrating from COBOL if you don’t get something better in return. What you should get in return is the flexibility to add new features and new user interfaces, the ability to adapt to changes in competitive conditions and implement changes in the regulatory environment, and so on. We don’t yet know what those new features will be (perhaps cryptocurrency or virtual reality user interfaces), but we do know that businesses will need the flexibility to add them.

    Simply put: Scrambling for COBOL programmers whenever there’s a crisis is not a viable business decision. Transitioning from COBOL is a change businesses will have to make eventually. This transition should be made when businesses have time to think it through, time to hire the right people and time to do a good job—rather than waiting for the next crisis.

    In the meantime, while businesses are baking in the time to think through their transition strategically, it’s important to note that this isn’t an all or nothing decision—i.e. let’s scrap our legacy software and replace it by Jan. 1, 2021. This is not Y2K. Using a microservices approach offers numerous advantage. For one, businesses can split their existing infrastructure into different independent services. They can start with pieces such as authentication, then move on to things such as billing and other services. Whatever businesses decide, they need an approach that’s modular so that it’s easy to add new features as needed. That requires careful thinking about design—and that thinking is more important than the programming language itself.