devopsy.kinsta.cloud

Category: Blogs

  • Open Source and the Mainframe with Rocket Software

    Open Source and the Mainframe with Rocket Software

    Open source enables developers to quickly create and deploy containers and business services across public and private infrastructures. Open source tools allow DevOps teams to harness the power of the mainframe.

    In this TechStrong TV interview, Tim Willging, chief architect and strategist, and Peter Fandel, mainframe open source evangelist at Rocket Software, join Mitch Ashley to discuss advancements in the use of open source software with mainframe apps and tools. Tim and Peter challenge some long-held beliefs around mainframes, open source software and the increasing role open source is playing today.

    Rocket Software is a global software development firm that offers enterprise products and services.

    The video interview is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: Hi everyone, I’m very pleased to be joined by a couple of great gentlemen here to talk about some interesting open source, security, mainframe, DevOps, all kinds of good things. So I’m pleased to be joined by Tim Willging who is chief architect and strategist for the mainframe business unit with Rocket Software and Peter Fandel, senior director of product manager mainframe open source. Welcome, guys.

    Tim Willging: Hello, thank you.

    Peter Fandel: Hello.

    Ashley: I think I might have said your name incorrectly, Tim. Is it Willging? I don’t know if I said that right. 

    Willging: That’s correct. That’s fine. 

    Ashley: Okay, good. Would you start? I’ll have you both introduce yourselves. Maybe you can also introduce the company, Tim, and then we’ll have Peter do the same?

    Willging: Sure. Yeah, I’m Tim Willging. As Mitch mentioned, I’m the chief architect and strategist for the mainframe business unit at Rocket. I’ve been with Rocket about 15 years and spent the majority of my career developing commercial solutions for the mainframe and mostly around database tools, DB2 tools. Rocket Software has been in existence for 25-plus years and is a privately held company and specifically we do software that’s not just on the mainframe but let me talk mostly about the mainframe software.

    Rocket has a development partnership with IBM and many of the solutions we develop are IBM branded; but we also have many things we’re doing Rocket direct; and open source, particularly the subject of this call, is one of those things that we also sell direct or partnership with companies direct to provide that open source. So Rocket has a long history with the mainframe and we believe in its future and in its sort of importance in the computing divisions across many of the largest companies of the world. 

    Ashley: Excellent. Great. Peter, if you would introduce yourself.

    Fandel: Sure. Peter Fandel, again. I’ve been at Rocket for 19 years. The great majority of those years in engineering management, and I took over management of the open source porting team about, four or five years ago and transitioned to product management about a year ago. And I manage both the open source porting portfolio as well as the Zowe portfolio, and both of those portfolios are critical components to the modernization story for the mainframe in large part because of the huge amounts of open source that are out there that you can _____ can get them running well on the OS as well as attracting talent, the next generation of developers. So that’s really our focus area for open source.

    Ashley: Excellent. You know, maybe you ought to start – and I started my career in the mainframe, too, and so I understand, kind of get where you’re all coming from in the market. There’s a lot of built up beliefs about mainframes and applications and whether you should think about porting or not or, you know, replatform them, leave them alone. Probably like you, I’ve learned it’s very costly and also fraught with danger to just go rebuilding applications, you know, because you think you want them on a different platform. You have to have a really good reason. But open source is actually a really important part of the mainframe ecosystem. I think maybe folks don’t really realize how important it is. How would you guys kind of set that up to give people an idea for the role that open source is playing in the mainframe environment today?

    Willging: Well, I’d start off by saying open source is incredibly important part of IT computing. I mean it’s something early career professionals are learning. It’s a huge way companies are running their business today and rather than writing things from scratch, many are starting with open source and then augmenting or augmenting existing systems with open source to modernize that open source because of its collaborative nature, how different companies and individuals contribute to that open source based on the needs of the industry. You really can’t separate the needs of our organizations that are running mainframes from that open source. Open source is a critical component of running your compute division. So without it, I think the mainframe would be, you know, would have a big missing part in what companies need to run their business today. 

    Fandel: I think also there’s a huge cost savings associated with that because you take any recent graduate and even not-so-recent graduate of any comp sci program and you ask them to start developing applications, they’re going to expect to build those applications on open source building blocks. And if they’re not there, your cost goes way, way up. As well, another area where open source is a must have is DevOps where if you want to – do you want to have a different DevOps tool chain for the mainframe than the rest of your organization or do you want to unify that? And if you’re going to unify it, it’s got to be open source based.

    Ashley: It’s a massive source of innovation and I don’t know if we’re here yet, but if we aren’t, we’re quickly reaching a point where you can’t operate a company, a software team without open source software. And if you aren’t using it, I can promise you your competitors are. So take advantage of it, right? Well, let’s talk a little bit about I know Zowe is of course a big important part of your strategy. Break it down for us. Go into a little bit more detail about where the places, roles that open source does play a role in the software development process and operational systems of mainframes, kind of paint that picture for our folks, our listeners.

    Willging: I think there are a lot of different ways it plugs in, but the one that I hear most of the companies I talk to is precisely what Peter just said. You know, the mainframe through many years of existence has been very waterfall-ish I’ve heard some companies because of the reliability. It’s the security, the maintainability of the mainframe that there’s a process which changes are rolled out in large batches. As companies modernize the mainframe and they start to add components to those mainframe applications that are off the mainframe, like in the hybrid cloud or have a web frontend or a mobile app frontend to a backend service or application that’s running on the mainframe, they want to be able to build, test, deploy the components of that application that go across the mainframe and those different computing platforms in the same manner.

    And to have tools, pipeline building tools, pipeline organization tools that have tools that build these environments, run the tests, destroy these environments, they need those open source tools to run on the mainframe to be able to drive those processes in a unified manner across all the different components of that application. So many companies today are just starting – you know, mainframe companies are starting on this journey. Many of them are hand rolling over the years have hand rolled sort of tools to try to have them plugged in, but that can get expensive as we’re talking about. So to get that open source running on the mainframe it’s important for them to be able to deploy those DevOps principles and practices in that application management lifecycle process. 

    Fandel: I would –

    Ashley: Very much so. Of course there’s also more with that too. Go ahead. I’m sorry, go ahead, Peter. 

    Fandel: I was going to build on what Tim said by introducing a really important distinction and that is that there is three very different ways you can get open source onto the mainframe. Most of the open source we’re talking about is units based. And you can do it by a Linux on Z, you can do it by a zCX Docker container or you can do it by UNIX System Services. And it used to be that the low cost way of doing that was Linux on Z and now more recently zCX because the porting is not much work to do because it’s all automated just port to the hardware which is done by compiles on those systems.

    But doing it on UNIX System Services is a lot more time consuming if you do it manually. But the advantage if you do port well on UNIX System Services is you’re close to the data. I mean if you’re running open source on Linux on Z or on zCX, it’s akin to running it on another machine on the network. You don’t have direct access to the data. Everything has to pass through TCP/IP. But UNIX System Services is part of z/OS and so you have direct access to all of the important data in your organization that MVS data. And that’s a key distinction. Where Rocket plays is open source on UNIX System Services on z/OS. So we are close to where the data is and we have solved the problem of high cost of porting through this GCC/GLIBC technology where we essentially automate the port of open source by simply compiling and linking in GCC and it injects the z/OS specific changes directly into the binary output of the build.

    Ashley: Talk about that process. Is that something that you’ve been doing a while? Of course going and changing binaries, most folks probably don’t do that as a natural first thought. But it does sound like a pretty straightforward way of minimizing the steps that you have to go through to get to begin using this. You can actually do it ____.

    Fandel: Yeah, it’s just we’ve been working on this GCC/GLIBC port in this manner for over two years, and it’s just coming to fruition now where in first quarter we will be releasing new versions of several of our ports that are not ported by hand. They are ported simply by building them with GCC, and we hope to have transitioned our entire portfolio by the end of 2021 to be built in this manner. And that means we no longer have to modify the source code because upstreaming is no longer a question, an issue. It means that we can turn around security vulnerability fixes much, much faster than we could otherwise.

    Ashley: I don’t mean this in a hyperbolic way or kind of playing up to you in any way, but that kind of an approach can be a pretty big game changer because you’re really asking people, it’s a low lift instead of a heavy lift to port if you will. 

    Fandel: Yeah.

    Willging: I’ve talked to many through the z/OS community who believe that due to the effort of going through these ports in the past, they felt that a better strategy was to run your open source close the mainframe – I say close with parentheses – or on a partition on the mainframe that’s running zLinux because the porting effort to get open source running on zLinux is minimal. And so they felt that the version currency, the security fix as Peter said, and the breadth of the packages available, open source source packages available on z/OS proper would always be behind. So they felt that was a better strategy to run it on zLinux.

    We don’t believe that at Rocket. We believe, as Peter said, that there are technical advantages to running that open source both from a DevOps standpoint but even more so from somebody who is looking to augment a legacy application say via some Python library that they’re looking to deploy where they’ve found some open source with a particular function. Running that Python on z/OS and accessing the data directly in concert with the legacy application that’s running or via some subfunction in that modernization effort is vastly different than running that Python in zLinux or on a machine off-platform and reaching into the data. The latency of what you can do, trying to embed that open source sort of in transaction, in the code in transaction becomes much more difficult to do. So we feel that Z customers as they’re looking to modernize will benefit greatly from opensource running on Z proper.

    Ashley: And as I understand, I think as you were describing it Peter, really you are talking about that compile process, right? That’s where you’re introducing GCC/GLIBC libraries. So that’s where this process is happening, changing things in a binary to adapt it to be able to use open source. Is that pretty much it or what else do you have to do to verify or test it or what are folks going to want to go through as they start to introduce this into the process?

    Fandel: Once we build it, we obviously have to run it through the test suites and we have two forms of testing. We have the built-in test suites that most open source products come with. I mean if you go to Git or Python and you download the source code from the community, it will be the product plus a huge volume of test code, self-test code. And so we execute that test code to make sure that it performs with the same results as on a test UNIX System. I think we used Ubuntu as the comparison and we compare the results. And if there’s any divergence on z/OS, then we inspect those divergences.

    And then in addition to that, we have a series of tests that test the z/OS specific capabilities that you want in open source. That’s mostly relating to the ASCII/EBCDIC conversion because z/OS and including UNIX System Service assumes EBCDIC is the default. Most of the data that you’re dealing with is in EBCDIC. And so our philosophy in porting on UNIX System Services, ASCII is the default internally. We compile with ASCII. Communication between open source packages and programs is in ASCII. But when you reach to the operating system, that’s where the conversion has to take place. So we have extra test suites for all of our ports that make sure the ASCII/EBCDIC conversion is taking place correctly both in file IO and pipes. So that adds to our testing process. So it’s not just build it and ship it. We do thoroughly test as well. 

    Ashley: That’s great. I’m glad you explained that too because there certainly are some fundamental differences in the operating system and environments down to the characters that –

    Fandel: Sure. 

    Ashley: – that we’re using. How about are there any kinds of applications that are more easier to port this way? That’s not the right way to say it. It’s not porting it but, you know, understand starting to use open source this way or others that maybe are a little more challenging, you might want to wait to take on that kind of an app? How would you recommend people get started?

    Fandel: Well, I mean we found that the porting a language is the most challenging because it just dips into every aspect of the operating system. So our conversion of the Python and Perl ports will be the last ones we release at the end of 2021. Our Python and Perl today are still, the ones we’re releasing are based on manual porting efforts. 

    Ashley: Okay, good. Any thoughts on that, too, Tim?

    Willging: I thought your question originally was like talking about a customer application they were looking to augment and add open source to what might be easier.

    Ashley: I would like to go there, too. That actually was my – but I’m glad you answered it the way you did, Peter. I’m curious from a customer perspective data intensive, things that are ultra-high security, high volume, lots of parameters can go into deciding what kind of an application you might use first to go down this path. Any thoughts on what you’d recommend to look at, to pick what app you might try this with?

    Willging: I mean there are a lot of mainframe applications that leverage CICS for online transaction processing and CICS is a great environment to deploy opensource. It’s been very forward thinking in its development to take and say a CICS application that’s written in COBOL and say you wanted to augment that via some modules that are written in open source language. That’s very possible and to make that communication really between the first thing you think about is there a runtime environment that’s involved, how do I want to lower that runtime environment so it doesn’t load every time that transaction is moving or it’s moving from the legacy code to the modern language?

    If there’s not, if it’s just a binary without a runtime environment, then you don’t have those types of concerns. So thinking about that and thinking through how you’re laying that out from an architectural standpoint and making sure you think through that. The speed of transition between legacy and open source language environments, that’s probably the biggest concern depending on what you’d like to do. But many companies have successfully done this and gone off and said, okay, we don’t want to necessarily go and rewrite my 30 million lines of COBOL. 

    Ashley: In a billing system probably not where I would start. 

    Willging: But there’s a new function we would like to add that potentially goes and augments via reaching to another system where customer data is available that you certainly can do that and many companies have done that successfully. Again, leveraging more modern languages and having that available for that augmentation is much cheaper, much less risk than is involved in a total rewrite and a re-platform which is again even then much of your language that you’ve written or much of what you’ve written won’t even necessarily run on a new system in the cloud. So replatforming is also very expensive or very risky depending on, again, the number of lines of code.

    Anyway, I probably went too far there but that’s sort of how I think about it from an online transaction standpoint. But a batch, different again, that you might just have some data that you want to reprocess and write a new output from that batch and augmenting there with open source is much easier because, again depending on the language can it run in batch, does it require to be hosted within a web server? But even then you can still have a batch process that alerts a web server to now go read this files so you can embed your open source within a say WebSphere Liberty or some web server that can go and even augment batch processes that way. It’s really getting the right architecture down first to say how you want to do that. 

    Fandel: Another area is data science and machine learning. You have for the past 20 years or so you’ve had academics and scientists and corporate engineers developing machine learning extensions, data science extensions, and they haven’t been writing those extensions in COBOL. They’ve been writing it in Python. And so that’s the go-to language for data science. 

    Ashley: It does give you access to a lot of new innovation just because of the language as well as the platform –

    Fandel: Exactly.

    Ashley: – and software stack differences. Two other areas I’d like to explore in our kind of time remaining, you mentioned DevOps and the role that open source plays in this. How does it help facilitate moving a mainframe application or developing a mainframe application now into more of a DevOps fashion? Are there some things inherent about because it is, you know, libraries that have a compile time process and there’s other tools? There’s Zowe and things like that can help you with interfaces and tool chains, workflows, things like that. What are your thoughts on that topic?

    Willging: Go ahead, Peter, you start. 

    Fandel: Well, I was just going to say that Git, since we release Git I think it’s three years now for z/OS, I think it was our number one download within 30 days of release. Everybody in the world is using Git now –

    Ashley: It starts with Git, doesn’t it?

    Fandel: – or Source Code Control. And so it, like I said before, just enables you to have a unified DevOps pipeline and that’s just huge. 

    Willging: Yeah. I mean to add to that, to have all of your source code in Git and then kick off a build process but then thinking of the mainframe and some of its legacy components like the parts of an application that help that make up the database. You know DB2 is very big on the mainframe. DB2 for Z. So to say that you can take those parts of the application touch the tables or smooth the tables in DB2 and extract those and then store those in a source code management repository because in DevOps you really want to store everything as code and represent everything in code so changes can be tracked over time. So taking open sourced, taking some even commercial tooling, taking some open source scripting languages, opensource to allow you to interact with a DevOps pipeline that’s running off the mainframe that’s driving the build and reaching in. You know, DevOps is really, again, not a product. It’s a culture and it’s a –

    Ashley: It’s a process. It’s a way of creating software, right?

    Willging: And so to build that DevOps pipeline using those tools but then have the tools – the DevOps tooling and scripting and running on the mainframe to be able to interact with the mainframe sometimes is a combination of open source, purchased tooling, and then hand rolling the pieces in between to fit your company’s needs. That’s really not possible. Again having a Git client for the mainframe and a lot of the other tools there are really important for that process. 

    Ashley: I’m curious about the security side of this. You know, a lot of application of air gap requirements things like that or the frequency or timeliness of security fixes. I don’t know if there’s a lot of difference between mainframe environments versus open source. That tends to happen of course more transparently. Maybe what are some of the advantages, pros and cons from a security standpoint of taking this approach?

    Fandel: Yeah, I’m glad you mentioned that because that’s one of the major changes that we have put in place this year with the introduction of the Rocket Open AppDev for Z Solution Bundle. We have switched from sort of old style, one at a time download of tarball and FTP it and then run through ten steps to set environment bevels and get it installed for each source tool or language. And as an example, GIT, which has four dependencies meant four or five downloads. Then you FTPed them over, and then you do the 10 steps four or five times. It’s like _____ way. We’ve switched to conda as the system for downloading, installing, and deploying open source on z/OS. That has made a huge difference in terms of the user experience and the ownership experience.

    So it’s now once you have conda installed on your mainframe, that takes about 30 minutes including the download and the setup, then it’s a single command to install Git and all of its dependency from the command line; and further, conda has this concept of a channel which is their word for a software repository or repository of software you download from. Conda supports something called a file channel as well as internet channels.

    So in addition to this, we have set up two internet channels at Rocket, one public one at anaconda.org that anybody in the world can use to download from and a secure channel server on our network that is authenticated for our customers on support. And then additionally you can set up a file channel which is on your premise which is ideal for air gap systems. So if you have an air gap mainframe, you don’t want it to have a connection to the internet, you can set up a file channel, populate it with the full contents of our bundle and then all of the developers within your organization can download at will from your on premise channels. That’s a big advantage in the area of security. 

    Ashley: Those some really big ones, big changes. 

    Willging: It is a big change. I mean there are a lot of companies that have said that the only delivery mechanism for software to my mainframe is through IBM Shopz. So you know, I have some feelings on that. I think that’s old school thinking as far as I’m concerned, but there’s still a culture amongst many mainframe customers that that’s it. I think that is changing and to make it simple, to guarantee that it’s secure and to provide options is what Peter just went through I think is important to help increase adoption of open source on the mainframe. And so Rocket is really leading in that area to help make that possible. 

    Ashley: It is culture. It is sort of tried and true. You know, if it’s not broken don’t fix it. But on the other hand, when you start to demonstrate new capabilities, new benefits, speed improvements, more security, whatever it might be, access to innovation, suddenly that becomes maybe a compelling reason to start to break down some of those traditions or barriers or kind of think about adding this as a capability. You’re not talking about changing everything, right? We’re talking about adding capability to how you create software in a mainframe and expanded environment, correct?

    Willging: Yep, exactly. 

    Fandel: Sure. 

    Ashley: Good, good. Well, where can folks learn more about this? I don’t know if you have any trials or free downloads or you’ve been in beta on some things that are GA or coming out in GA. What’s the best way for folks that want to engage with you and find out more and kind of give this some –

    Fandel: I think you can Google z/OS Miniconda. You can Google Rocket Open AppDev for Z which is the product release from September and that will lead you to our product pages, our download page, documentation on how to install z/OS Miniconda which is the bootstrap to get you started. There is a couple of published videos. If you look at the Open Mainframe Projects Summit from September and look for, under the video there, “Demonstrating a Secure System for Downloading and Installing Software on z/OS,” you’ll find a video there that shows how it’s used. 

    Willging: The only thing I’d add to that is go check out zowe.org.

    Fandel: Thank you, Tim, yes, absolutely, zowe.org.

    Ashley: Don’t want to look past that, of course. 

    Willging: It completes everything else Peter said. 

    Ashley: Very important. 

    Willging: Important stuff. We haven’t really talked much about Zowe, but yeah. 

    Ashley: We’ll have a chance to do that. Would love to have you back and we can delve into that. I really would like to explore some more about this delivery of software into production and how do we start to evolve and expand helping more organizations consider how they might do that so there will be some great areas to explore further. So look forward to doing that with you. It’s been a lot of fun talking. Any parting thoughts before we wrap things up here?

    Willging: Just real quick, I’d encourage those mainframe z/OS shops, if you don’t have a policy for downloading, consuming open source, I encourage you to get your thought leaders together, you know think about the advantages that open source will provide in your modernization efforts. Check out zowe.org but create a policy to not only to consume but contribute. Get involved in the projects. It’s a way to expand your employees’ interest in the mainframe to make that open source there available. So if you haven’t done it, you really should do that. 

    Ashley: Access to more talent I think as Peter was mentioning earlier. It really is opening up new pathways as opposed to replatforming and a lot of not very attractive options sometimes that you now have because of open source. So folks definitely should consider this, look at it, get into it, get involved. Great. Well, gentlemen, it’s been great talking with you, both Tim Willging and Peter Fandel from Rocket Software. Take care, gentlemen, we will see you next time. 

    Willging: Thank you.

    Fandel: All right, thank you. Take care. Bye-bye.

    Willging: Bye.

  • Thread is the Future of Wireless Mesh

    Thread is the Future of Wireless Mesh

    Over the last decade or so, interest in IoT technology and connecting devices to one another, and to the internet, has increased. Of course, one of the key elements necessary to connect devices is wireless communication. There are several wireless interfaces, such as cellular, Wi-Fi, Bluetooth, ZigBee, LoRa etc., that are prominently used in different industries to make these connections. However, choosing the right wireless technology is vital for the success of any product. One should consider several factors before zeroing in on the right wireless technology for your goals. Some of the factors to consider include:

    • Wireless range/ coverage
    • Throughput
    • Power consumption
    • Scalability
    • Security
    • Ease of provisioning

    Selecting the right technology to get the best results and satisfy all your requirements is a challenge, and what’s “right” may vary depending on use case. For instance, cellular technology is often preferred for a mobile device used in logistics applications, as it has excellent coverage. However, cellular technology is power-hungry; it would be difficult for the battery-powered device to operate for long periods of time. Similarly, LoRa, with a wide wireless range and low power consumption, is an excellent choice for applications such as smart metering. But it has a relatively low data throughput, and therefore may not be the ideal choice for certain industrial applications.

    What is Thread?

    One of the recent entrants to the wireless communication space is Thread. Thread is an IPv6-based, low-power, open source, mesh networking protocol for connected devices, backed by Nest Labs (a subsidiary of Google) and other industry bigwigs. Like ZigBee, it uses IEEE 802.15.4 wireless mesh protocol, but, being internet protocol (IP)-based means a Thread network can seamlessly connect to the internet without needing a translator or a gateway in between. Thread operates on the 2.4GHz ISM radio band, the same as ZigBee, and offers a throughput of 250 kbits/s with a typical range of about 30 meters. It employs spread-spectrum techniques to provide immunity to interference. Thread’s low power consumption means that a coin cell could power it for almost two years.

    Thread as a Mesh Network

    As a mesh network, Thread can have several hundred devices communicating with each other and the cloud. A typical Thread network would consist of an endpoint device, router node and a border router. A typical endpoint would be a battery-powered device that communicates with a parent router. A router node would receive packets from devices on the network and forward them to the rest of the network. The border router is a device that facilitates communication between a Thread network and a non-Thread network, such as Wi-Fi or Ethernet, by forwarding packets.

    Benefits of Thread

    Because Thread is a self-healing mesh network, it offers many benefits. One is avoidance of a single point of failure. That is, if any router in the network fails, another router automatically takes its place. Unlike ZigBee, for example, Thread devices can be linked to multiple border routers, making the network more reliable. Another advantage is that, being mesh, the Thread network is highly scalable. Each Thread network can scale to hundreds of devices. Thread also benefits from being built on IPv6 to take advantage of end-to-end routing and addressability. Any two IPv6 endpoints, whether on the same Thread mesh or across networks, can communicate, end-to-end, with easy and well-understood internet routing mechanisms moving packets from one endpoint to the other.

    One of the biggest benefits of Thread is that it can provide a high level of security. Security breaches associated with IoT and connected devices are on the rise, and are a major barrier to legacy device connectivity. All devices in a Thread network are automatically authenticated and communication is encrypted. Thread networks use a secure, financial-class encryption and the technology has plugged the obvious security loopholes found in other wireless protocols.

    An IoT device should be easy to deploy in the field, which is another factor in selecting the right wireless technology. Thread devices can be easily set up using a smartphone or a tablet. Users can securely connect devices to each other, and to the cloud, for easy control and access from anywhere.

    Thread is built on 6LoWPAN, which is the same radio protocols as that of ZigBee; an IEEE 802.15.4-based specification for high-level communication used to create personal area networks with digital radios. It’s possible that, with just a software upgrade, an existing ZigBee module can be converted to a Thread module. For legacy ZigBee users, it would be relatively easy to migrate to Thread technology. Availability of OpenThread, an open-source implementation of Thread, is likely to accelerate the development of products that leverage Thread. However, the limited availability of off-the-shelf border routers, and the use of less preferred mesh topology, is a challenge for its adoption into IoT devices.

    The Future of Service Mesh

    Thread has great potential, and can be considered a very good alternative to existing wireless communications options with the added benefit of Wi-Fi-like features. Because it’s open source and backed by large semiconductor manufacturers and technology heavyweights, Thread technology is poised to gain substantial momentum over the next few years. It may eventually emerge as the primary choice for medium throughput, low power IoT applications.

  • Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri today unveiled a platform-as-a-service (PaaS) environment through which developers can embed geospatial capabilities into their applications by making an application programming interface (API) call to a cloud service.

    Euan Cameron, CTO for developer technology at Esri, said the ArcGIS Platform will make it simpler for developers to incorporate mapping capabilities enabled by a geographic information system (GIS) system with, for example, a mobile application. The entire ArcGIS software stack can be accessed by those applications by making an API call. Previously, IT teams would have to stand up the entire Esri platform on their own to provide development teams with access to the Esri geospatial platform.

    The PaaS environment also makes it possible for developers to access professional-grade geospatial content that can be plugged directly into their applications, Cameron said.

    Geospatial platforms gained prominence with the popularity of mobile applications that require mapping capabilities. With the expansion of 5G wireless networks, the number of applications that require similar capabilities will continue to grow, Cameron said. A PaaS environment that abstracts the complexity of managing a geospatial platform behind a set of APIs will make it easier to build those applications at scale, Cameron said.

    There are, of course, other approaches to making geospatial databases available as a service. However, Cameron said Esri has long history of providing these capabilities alongside content it curates across a wide range of consumer and business applications. Those capabilities are now an API call away from any application, Cameron said.

    Of course, DevOps teams will need to integrate a PaaS environment that can be invoked as a cloud service within their overall workflow. Esri is committing to making its PaaS offering available on a global network of data centers to minimize latency for applications making API calls to its platform.

    These days, it’s hard to imagine an application that doesn’t require at least some degree of geospatial capabilities. Time and place have become critical elements of any application experience. The total cost of providing those capabilities drops considerably when the geospatial platform required to enable them is managed by its provider. In fact, as application development continues to evolve, DevOps teams often find themselves orchestrating a broad range of API calls to external services. Each one of those calls is simple enough, but over time, the sheer number becomes challenging to manage. Nor is the quality of the APIs surfaced by each service always of the same quality.

    Regardless of how geospatial capabilities are integrated into an application, the days when dedicated teams managed complex GIS platforms may finally be coming to an end.

  • Sentry Updates Tool for Monitoring JavaScript Apps

    Sentry Updates Tool for Monitoring JavaScript Apps

    Sentry today announced it has updated its JavaScript SDK tool for monitoring applications to provide a more comprehensive view of application health.

    Previously, Sentry’s JavaScript SDK enabled JavaScript developers to insert lines of code that would tell them, for example, how many times an application failed. A new release health capability now also identifies what percentage those fail instances represent of the total number of times that application was successfully launched.

    Developers can, in effect, better gauge adoption of a JavaScript application by tracking the percentage of crash-free sessions and crash-free users over the application’s life cycle.

    Ben Vinegar, vice president of engineering for Sentry, said the JavaScript SDK is designed to provide developers with a monitoring capability that doesn’t require an IT operations teams to stand up and manage an entire application performance management (APM) platform. That approach also eliminates the need to instrument JavaScript applications with agent software, Vinegar said.

    The JavaScript SDK consumes tens of kilobytes of memory after it is embedded directly within a JavaScript application, said Vinegar.

    In general, JavaScript is increasingly being used to build complex applications, using frameworks such as React, as an alternative to Java. Over the years, IT organizations have developed a certain amount of bias around how Java applications should be monitored and managed using APM platforms. However, as JavaScript developers assume more responsibility for their applications after deployment, they need real-time monitoring tools that can consume JavaScript application metrics and are built in to existing APM platforms, .

    Of course, APM platforms are managing more than just JavaScript applications, so they’ll remain useful for the forseeable future. However, ease of observation and monitoring is a significant factor when application developers choose a language in which to build an application, and it’s up to individuals to remediate issues that might arise in production. Developers, therefore, have a vested interest in discovering potential issues before that application is deployed.

    Historically, developers have not had access to JavaScript application monitoring tools that they could easily implement on their own. Sentry’s tools makes it possible for developers to identify performance issues, including calls to application programming interfaces (APIs) and other common errors, and address those before an application crashes.

    It’s possible, as performance and security issues shift left and developers become more accountable for user experience, that developers might one day instrument and monitor applications on their own – if for no other reason than self-preservation. Every minute a developer spends remediating a production issue in an existing application is one less minute they will have to write new code.

  • A Pragmatic Approach to DevSecOps

    A Pragmatic Approach to DevSecOps

    In response to market and competitive forces, many companies are using DevSecOps to develop higher quality and more secure software. Whether that software is their own product or is a component of their product, quality – and especially security – have become required rather than optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can, and has, caused significant disruption.

    Barriers to DevSecOps Adoption

    The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked with ensuring applications are secure and that policies are being followed. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little, too late,” as the security team is usually involved near the end of the development life cycle. Attempts to “test in” security rarely succeeds. Security needs to be built in from the start; “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:

    • Lack of motivation and awareness:  There’s a lack of awareness about security issues, and about the risks and impacts security vulnerabilities pose to the organization in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This indifference remains, even when 63% of companies had, or nearly had, vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
    • Distrust: Lack of trust between teams is expected in most organizations, but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success, and security teams view developers as incapable of delivering secure software.
    • Poor Perception: The prevailing view of security is that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security, then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – with disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug, with subsequent impacts on time-to-market, budgets, product quality and reputation.
    • Gatekeeping: The security team sometimes acts as gatekeepers of release candidates, which is a source of friction between developers, testers and security experts. Placing security as a last, QA-like step before delivering a release is too little, too late. Developers also don’t like other teams imposing restrictions on their work, which is an issue when trying to put security controls, like secure coding practices, in place.
    • Lack of integration: Without integrating security practices and tools through the entire development process, security improvement initiatives have trouble getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.

    These barriers might seem daunting, but it’s not unlike other corporate cultural shifts. Security teams need to delegate aspects of security to development teams and integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality, but lack some of the basics of good security practices.

    It doesn’t need to be this way. However, removing these barriers won’t happen overnight, so a practical and gradual approach to improving security is needed.

    Easing Your Way into DevSecOps

    Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams, and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain, and the initiative fails. As with any large task, it makes sense to start small; to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.

    Start Small

    The alternative to the doomed “big bang” approach is to start with a small, motivated team, where it’s possible to implement new practices from the very beginning of a project. By keeping the scope, and thus, the technical and business risk, of the project smaller, it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project, where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn, and then teach the larger organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps, and kick off the organic growth needed for a smoother transition.

    Starting small extends to the use of new tools, as well. It’s one thing for a small team to adopt new technologies, but they can be quickly overwhelmed. Static application security testing (SAST) tools can produce a lot of information. It’s important that initial projects concentrate on high impact, high probability vulnerabilities, first and foremost. It’s easy to get bogged down in the details, and discipline is needed to focus on the highest impact, and to get the most ROI out of new tools.

    Start at the Beginning (Or as Early as you Can)

    This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools, and become proficient at using them. It’s at these early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities, and adopting more secure design and coding practices, greatly reduces the downstream impact. It’s not hard to justify the effort, when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.

    Measure Success

    The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working, it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these statistics are known, then it’s a case of measuring how well the new project does versus the baseline performance.

    Other metrics are important, too, such as measuring the number of vulnerabilities detected, identifying those that are true risks and those that were removed through corrective action. SAST tools provide information on a per-build basis, so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time; are they converging to a goal? How quickly is the convergence?

    The ultimate measurement of success is a more secure product and, ideally, security testing at the later stages of development should find fewer vulnerabilities than in the past. After building in security and starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed more quickly.

    Start your DevSecOps Transition

    The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical that tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse-based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risky, cheaper and easier.

    Equally critical is establishing an initial baseline inventory of your third-party software assets, whether that is open source, reused internal code from other projects and/or third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets! Software composition analysis (SCA) is critical throughout the development process since the open source and third-party software that you depend on is likely to have updates and introduce new security threats over time (including after you release the product).

    Early adoption of SAST and SCA tools can have many benefits as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:

    • Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools provide all the necessary information to fix potential vulnerabilities, but also provide an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities, and learn to avoid them.
    • Illustrate ROI by measuring success, and have a goal in mind. Eliminating just one serious vulnerability justifies much of the investment. However, communicating this ROI is important, and needs to be put in the proper context of how costly and risky vulnerabilities are once a product is released.
    • Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust, then check” approach. Developers learn more about secure practices over time, and integrate that knowledge into their existing workflow. In the end, there is no security team gate at release, and all members of the team know and understand the state of the product.
    • Integrate security practices into software development gradually, starting with a small team and small project. As experience is gained, these teams train the rest of the organization on best practices.

    DevSecOps From the Ground Up

    DevSecOps is a way to build security into an application, and the transition from an existing CI/CD and DevOps process is made easier with the right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A “start small and start early” approach is recommended where new techniques, processes and tools, such as SAST and SCA, can be integrated with less downtime and cost.

    Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress, but communicating the ROI needs to be done in business terms. In the end, success results in a more secure product, and reduces your company’s exposure to data breaches and cyberattacks.

  • The Value of Trademarks

    The Value of Trademarks

  • DevSecOps Implementation: SIEM

    DevSecOps Implementation: SIEM

    The world is filled with events. Our inbox floods with events that marketers really want us to pay attention to, while news feeds flood us with events they’re trying to raise above the background noise, but then, the dog barking interrupts our consumption of that information. Our family is, meanwhile, texting us about events on the family level that may be related to events on the national or world stage … meanwhile, social media is full of garbage information about events that may or may not be real, and that you may or may not care about.

    We ignore the vast majority of these inputs and move along with our day. The inputs that require our attention usually, but not always, get it. Sometimes, we fail horribly at filtering, judging importance, or both, and it has life-impacting ramifications.

    This is not too far from the state of security event management when security information and event management (SIEM) was born. Disparate feeds were coming in from all over; analysts – be they dedicated security folks or systems administrators wearing an extra hat – had to guess which of dozens, hundreds or even thousands of events were a real threat to the environment.

    The first step to gaining control of that environment was standardization and aggregation. Get the events into one place, with similar information available for similar events. That was where SIEM came from.

    Since then, the number of events coming in has continued to rise. Companies that were seeing hundreds of events a day are now seeing hundreds an hour, and SIEM vendors had to keep up. The complexity of attacks, and the ability to detect them, has gone up, and SIEM vendors have had to keep up. Tools available for feeding the SIEM and for acting on the aggregated data have evolved … and SIEM vendors had to keep up.

    At this point in time, SIEM is best characterized as a data aggregation platform with limited intelligence that aids in filtering of irrelevant events. It’s akin to turning off social media and telling those close to you to call if needed; it filters out the worst noise and elevates the most important messages.

    Other tools can analyze their own data and make their own deductions, but SIEM is where you bundle all security-related events in one place, so it is the logical place to filter the noise and raise awareness. But it requires a high-volume, adaptable datastore. Vendors have reached that plateau.

    Once volume issues were mastered, SIEM vendors turned to helping filter the insane volume of security event noise. Yes, it is a security event if Bob logged in on a new workstation, but it probably isn’t a noteworthy security event. Unless Bob’s new workstation is in a country where the company doesn’t do business, or Bob is still logged in on his own workstation, blissfully unaware of the other login.

    So, rudimentary filters were applied to the event data in the SIEM. This got rid of a huge amount of noise. Next came filtering events that, logically, looked like notable security events, but just weren’t. Something was scanning ports on the firewall. An internal firewall. Sounds bad, unless the security tools’ logs showed that an authorized user kicked off the scan. Then, it’s a simple matter of asking the user in question, “Are you scanning X?” and moving along. It’d be better for the system to lower the importance of the event based on the fact that it is an authorized user doing the scanning, with corporate-approved tools. Then, an analyst may not need to get involved at all (my security friends are cringing because, literally, they trust no one, and would point out that authorized users can misuse tools, too – so I’ll note that here).

    But the event volume kept going up, and the analysts were even more swamped. Between adding new reporting apps (HIPS alone can add thousands of reporting points to a SIEM), and increases in events on existing monitored points, it was ugly.

    Enter AI. This is when machine learning (ML) started becoming the norm in SIEM. Now, we want the system to avoid using hard-and-fast rules that must be maintained, but to use knowledge it gains by watching the flow of data and an analyst’s resolution to selectively raise/lower the priority of events. Now, the events that actually bubble up to analysts are ones that the ML engine sees as fishy, and the number is greatly reduced. False positives still occur, but not nearly at the volume they did before, as the system learns how to detect them.

    But wait! There’s more!

    All that data in one place with ML engines crawling over it was just too much temptation for data scientists and deeply knowledgeable security personnel. So, the ability to plot a course through seemingly unconnected security events and determine that this or that was actually evidence of intruder or attacker activity spread across the system came next. This is where we are now – the ability to connect the dots on events that analysts (or the system) might have filtered out to find patterns that indicate intrusions.

    But it comes with a price. It’s not cheap to set up, it’s not easy to train, and maintenance of a system that takes inputs from everywhere and tries to correlate the resulting dataset is … work. We’re not talking a little bit of data here, and, like the environment it comes from, we’re not talking a little bit of complexity. Do you need it? I would say yes. Even if you only use SIEM as a big data store, it will help you perform post mortems when (not if) you have a breach. It is worth the effort, unless you are tiny or have no Internet presence to speak of.

    Keep rocking it! SEIM is another tool to consider as you move to DevSecOps dominance, but again, just a tool that requires you to keep the org safe.

  • Logi Analytics Announces New Analytics Dashboard Experience for BlueVolt Platform

    With Logi Info, BlueVolt equips platform with new analytics and reporting dashboard functionality to empower channel-focused partners

     

    MCLEAN, VA — January 26, 2021— Today, Logi Analytics, the leading provider of embedded analytics solutions for software teams, and BlueVolt, an award-winning authority of online learning solutions for sales and channel marketing, announce a new partnership utilizing Logi Info to create a cutting edge analytics dashboard experience for all BlueVolt customers. With the upcoming BlueVolt analytics dashboard, customers will have better insight than ever before into their channel partner education and training strategies.For channel-focused companies, consistent engagement, training, and partnership development are critical to long-term business success. But not all training and marketing strategies are created equal. In fact, many businesses continue to invest time, money, and personnel into outreach strategies that aren’t providing timely data or sufficient ROI. That’s why BlueVolt invested in Logi Analytics to create a new suite of dynamic and easily understood embedded analytics dashboards for BlueVolt platform customers. These dashboards provide users with the tools and insights they need to quickly leverage real-time updates and position their companies for success.

    “BlueVolt’s platform is a perfect example of why embedding powerful, actionable insights into the application is the key to unlocking better business growth in the modern marketplace,” says Charles Caldwell, Vice President, Product Management at Logi Analytics. “Our solutions empower end users to aggregate, analyze, and act upon data insights without having to leave their application workflow. With Logi Info, BlueVolt can customize and create a whole new analytics and reporting experience for its partners.”

    BlueVolt initially selected Logi Analytics for its analytics needs based on Logi Symphony solution suite’s customization and flexibility. Now, BlueVolt has access to the full Logi Analytics portfolio — notably including Logi Info for the current platform updates. These solutions are proving critical to BlueVolt’s partners, all of whom need to quickly analyze and respond to real-time market and customer data to gain a competitive advantage.

    “Our partners need to make data-driven decisions, and they need a way to visualize that data throughout the process,” says Gaven Singh, Vice President of Strategy & Business Development at BlueVolt. “Recent studies from Deloitte show that every dollar spent on business intelligence can return nearly $30 in increased productivity, proving that smarter businesses are stronger businesses. With BlueVolt’s new BI functionality, our partners will reap the benefits of viewing all their data in live time, and Analytics has been critical to making this possible.”

    For more information on Logi Analytics, visit https://www.logianalytics.com/. For more information on BlueVolt, visit https://www.bluevolt.com.

    ###

    About Logi Analytics

    Logi Analytics empowers the world’s software teams with the most intuitive, developer-grade embedded analytics solutions, along with a group of dedicated people invested in your success. Logi leverages your existing tech stack, so you can quickly build, manage, and deploy your application. And because Logi supports unlimited customization and white-labeling, you have total control to make the application uniquely your own. Over 2,200 application teams have trusted Logi to help power their businesses with sophisticated analytics capabilities. Logi Analytics was recently awarded the 2020 “Best Business Intelligence Solution” Proddy award by Product School, in addition to being named a leader in Business Application Research Center’s (BARC) BI & Analytics Survey 21 across several categories, including Operational BI, Embedded BI, and Cloud BI.

    Logi Analytics is headquartered in McLean, Virginia, with offices in Ireland, England, Ukraine, and China. Learn more about what’s possible with Logi at LogiAnalytics.com.

    About BlueVolt

    Winner of numerous awards, including “High Performer Enterprise” 2020, “Easiest Admin Enterprise” 2020, and “Best Learning System” 2019, BlueVolt consistently ranks as the top learning and marketing platform while always providing world-class customer service.

    Since 2003, BlueVolt has been a pioneer in the online learning industry. The secret to BlueVolt’s success is its sharing network—sharing more than half a million pieces of product training from various industries and manufacturers. Relationships matter to BlueVolt, which is why they built their platform to link a wide range of organizations together. The BlueVolt platform connects and supports all customers, giving them the tools to increase their sales, build brand leadership, and enhance employee knowledge.

    BlueVolt is headquartered in Portland, Oregon. Learn more about BlueVolt and join the largest sharing network out there by visiting BlueVolt.com

     

  • Commvault Debuts Major New SaaS and Hybrid Cloud Workloads for Metallic, Continues Global Expansion

    Metallic adds new support for Salesforce backup, Microsoft Teams, Oracle Databases, Active Directory, and HyperScale X for Metallic, expands availability in Europe

     Tinton Falls, N.J. – January 26, 2021 – Commvault (NASDAQ: CVLT), a recognized global enterprise software leader in the management of data across cloud and on-premises environments, today announced another expansion of its award-winning Metallic Backup-as-a- Service (BaaS) portfolio. On the heels of last quarter’s accelerated innovation, Metallic is adding new data protection solutions, features, and enterprise workload support including: enhanced SaaS application protection with the introduction of Metallic Salesforce Backup and Microsoft Teams recovery enhancements; the addition of Oracle and Active Directory to Metallic Database Backup; and the expansion of its hybrid cloud capabilities with the addition of HyperScale X as a fully integrated appliance and edge offering for Metallic.

    In addition, Metallic is now generally available in 23 countries in total, announcing support for nine new countries in the EMEA region today, including Austria, France, Germany, Norway, Poland, Portugal, South Africa, Spain, and Switzerland.

    “As we continue our global rollout of Metallic, we’re finding more and more customers around the world are immediately grasping the value and inherent simplicity that cloud-native, as-a- service data protection can bring to their environments,” said Manoj Nair, General Manager, Metallic. “With our new offerings like Salesforce and Oracle backup and our unique SaaS Plus capabilities, Metallic solutions offer customers what no other cloud-delivered backup service can match: the most comprehensive portfolio of BaaS solutions and the flexibility to backup each data source to the optimal storage target–whether that be cloud or on-premises storage, or the new HyperScale X for Metallic at the edge for ultimate performance with BaaS simplicity.”

    “The rise in both remote work and potential data risk is driving strong demand for cloud-based data protection solutions that offer customers the security, agility, and functionality needed to not only continue day-to-day operations, but in many cases, to exceed them,” said Vinny Choinski, Senior Validation Analyst, Enterprise Strategy Group. “With the continued expansion of Metallic’s SaaS Plus portfolio, Commvault has created an impressive backup-as-a-service ecosystem – a comprehensive range of offerings supporting enterprise-wide workloads to the backup target of choice, whether it’s on-prem, in the cloud, or to the HyperScale X appliance.”

    New Metallic Solutions

    Understanding that businesses across the globe need dedicated protection for their SaaS applications, Metallic has made global availability a top priority, tripling its country availability and doubling its product offerings. Recent additions include hybrid cloud data protection solutions for SAP HANA and Kubernetes, in addition to today’s newest enhancements:

    • Metallic™ Salesforce Backup provides customers scalable, enterprise-grade SaaS data protection for the Salesforce Sales, Service, and Financial Cloud. It offers simple protection for valuable Salesforce data with unlimited retention, unlimited storage, and hardened security controls built-in – helping to meet stringent standards, unique requirements like sandbox seeding, recovery requirements, and
    • Metallic™ Office 365 & Teams Backup & Recovery now builds on Metallic’s existing Microsoft Teams capabilities to include in-place restore of Teams conversations and other data. This enables administrators to granularly recover data stored within Teams, channels, and conversations, with better speed and precision while maintaining existing site structures and settings. All new and existing Metallic Office 365 Backup customers will automatically receive Microsoft Teams functionality as part of their subscription – which also provides coverage for Microsoft Exchange, SharePoint, and OneDrive.
    • HyperScale X for Metallic offers customers the choice of a fully integrated appliance for single-vendor management of on-premises storage and SaaS-delivered data It enables the Commvault appliance, HyperScale X, to run in edge mode, allowing it to operate as a backup target for hybrid cloud workloads protected by Metallic. This innovative edge offering represents the next step in Metallic’s hybrid expansion, combining the best of Metallic BaaS with the best of the HyperScale X scale-out storage platform. Customers can use Metallic to protect data in any hybrid data protection schema, whether cloud to cloud, on-premises data to cloud with an on-premises copy for fast restore, cloud to edge appliance, and more.
    • Support for Oracle Database and Microsoft Active Directory backup are now offered as part of the Metallic™ Database Backup Providing BaaS database protection for customers’ hybrid world, Metallic Database Backup gives administrators seamless visibility and database protection for SAP HANA, Oracle, Microsoft SQL, and Active Directory on-premises, in the cloud, and in Azure.

    For more information about Metallic’s cloud-native data protection solutions and availability, please visit www.metallic.io.

    About Metallic™

    Metallic™, A Commvault venture, was established to bring next-generation software-as-a- service (SaaS) data protection to the market, delivering Commvault’s powerful core technology simply through the cloud. Together with its partners, Metallic offers a growing portfolio of SaaS backup and recovery solutions to help today’s companies keep their data protected, compliant and safe from deletion, corruption and attack. Metallic operates as a division of Commvault and can be found at http://www.metallic.io.

    About Commvault

    Commvault is a worldwide leader in delivering data readiness, enabling customers to intelligently manage data with solutions that store, protect, optimize and use data. Commvault software automates mind-numbing IT tasks and makes data work harder for customers— so they can gain invaluable insights for their businesses. Commvault solutions work across cloud and on-premises environments, leveraging the digital tools and procedures already in use.

    Commvault software, solutions and services are available from the company and through a global ecosystem of trusted partners. Commvault employs more than 2,300 highly-skilled individuals across markets worldwide, is publicly traded on NASDAQ (CVLT), and is headquartered in Tinton Falls, New Jersey in the United States. Visit Commvault.com or follow us at @Commvault.

     

    Safe Harbor Statement: Customers’ results may differ materially from those stated herein; Commvault does not guarantee that all customers can achieve benefits similar to those stated above. This press release may contain forward-looking statements, including statements regarding financial projections, which are subject to risks and uncertainties, such as competitive factors, difficulties and delays inherent in the development, manufacturing, marketing and sale of software products and related services, general economic conditions and others. Statements regarding Commvault’s beliefs, plans, expectations or intentions regarding the future are forward-looking statements, within the meaning of Section 27A of the Securities Act of 1933, as amended and Section 21E of the Securities Exchange Act of 1934, as amended. All such forward-looking statements are made pursuant to the safe harbor provisions of the Private Securities Litigation Reform Act of 1995. Actual results may differ materially from anticipated results. Commvault does not undertake to update its forward-looking statements.

    The development and timing of any product release as well as any of its features or functionality remain at our sole discretion.

     

    ©1999-2021 Commvault Systems, Inc. All rights reserved. Commvault, Commvault and logo, the “C hexagon” logo, Commvault Systems, Commvault HyperScale, ScaleProtect, Commvault OnePass, Unified Data Management, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, Quick Snap, QSnap, IntelliSnap, Recovery Director, CommServe, CommCell, APSS, Commvault Edge, Commvault GO, Commvault Advantage, Commvault Complete, Commvault Activate, Commvault Orchestrate, Commvault Command Center, Hedvig, Universal Data Plane, the “Cube” logo, Metallic, the “M Wave” logo, and CommValue are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.

     

    # # #

  • Overcoming Cloud Asset Management Challenges

    Overcoming Cloud Asset Management Challenges

    Twenty years ago, no one in IT could have predicted the monumental role that cloud computing would play in our everyday lives. To play off the words of Back to the Future‘s Doc Brown: “On-premises? Where we’re going, we don’t need on-premises.” As technology continues to evolve, though, security teams face greater challenges.

    Infrastructure is no longer server rooms and boxes; it is dynamic, changing constantly to support fluctuations in demand. And moving to the cloud introduces new third parties into the digital mix. Although AWS, Google, and other cloud providers have a lot at stake when it comes to protecting customer data, security responsibility is never completely out of an organization’s hands. Compliance considerations are yet another complicating factor. In many cases, regulations around data access, privacy and residence were created for an on-premises world.

    Looking to the future, companies want to maximize their investments in the cloud, while better addressing these security challenges. However, the rapidly changing nature of the cloud makes it difficult for security teams to fully understand the scope of assets they are responsible for at any given point in time, which is an absolute necessity in order for companies to truly be secure. After all, how can a company make sure it has no gaps in its cloud security if it can’t account for all cloud assets – especially when working with multiple cloud providers?

    Security teams need to inventory their entire cloud infrastructure, understand what controls are in place and find ways to detect and mitigate any vulnerabilities or misconfigurations in a timely manner.

    Understanding Cloud Workloads

    When moving assets to the cloud, it can be incredibly difficult to try to inventory devices with dynamic IP addresses, which constantly change, compared with more static devices. The mass adoption of containers and microservices, some of which exist for just seconds before disappearing, make dynamic systems even harder to track.

    One of the most important improvements that have come out of cloud growth is that everything has an API, which can be a massive advantage when inventorying assets. Because each cloud provider is self-contained, finding out when a new bucket or instance is created is certainly possible. Organizations that have advanced development capabilities can write and maintain their own applications to identify every new cloud instance for each provider – but doing this for multiple cloud providers and correlating cloud asset inventories with other security control data becomes a major investment of resources. The ability to access all resources in the cloud makes asset management a more achievable goal.

    Security Controls

    It is essential for organizations to carefully manage their assets and understand the security controls in place to know exactly what they cover. By categorizing their resources, companies not only better understand what they have, but can make informed decisions about exactly what additional security measures need to be taken. For example, vulnerability scanners may not be scanning critical workloads – or perhaps dedicated cloud workload protection platforms need to be deployed for certain cloud assets. It can be incredibly difficult for security systems to keep up; since cloud assets can be created so quickly, they need security systems tailored specifically to keeping them safe.

    A security tool can only secure devices that it knows exist. Once an organization understands the assets it has, it can expand the coverage of any existing tools to devices that were previously unknown. When that coverage is fully adopted, asset management can help the organization find gaps in its coverage to identify areas for additional protection and the right tools to secure them.

    Addressing Vulnerabilities and Misconfigurations

    Once an organization establishes a comprehensive asset inventory and visibility, the next step is to address vulnerabilities, gaps in coverage or misconfigurations that are found. With the ability to spin cloud instances up or down at will, it is inevitable that instances may be forgotten and inadvertantly left unprotected. Since cybercriminals automatically scan public cloud infrastructure to exploit these types of vulnerabilities, public-facing cloud workloads are especially at risk.

    Similarly, finding and addressing misconfigurations in cloud workloads becomes more complex. With the highly configurable nature of the cloud, mistakes happen often, and without proper security controls in place to detect these misconfigurations, attackers can easily access and steal data. Organizations must implement a process to continuously detect cloud workload misconfigurations.

    A great place to start is the Center for Internet Security (CIS) Benchmarks, which provides objective security guidelines. By comparing data from each cloud provider with the rules in the CIS Benchmarks, security teams will be able to identify assets that don’t adhere to best practices.

    The key to maintaining security in a modern cloud environment is to implement continuous discovery and interrogation, which requires automation. This includes the ability to create tailored alerts when certain conditions are met, and automatically deploy and change security controls as needed. Teams should set restrictive access controls by default so that non-approved users don’t have access to sensitive data. Any time a cloud workload deviates from policy, there should be a plan in place to automate the corrective action.

    Computing technologies continue to evolve at a staggering pace. The computing environment 20 years from now won’t resemble even the most far-fetched, futuristic ideas today. The evolution of cloud adoption from justified skepticism to ubiquity taught us an important lesson: change is constant. It is incumbent upon technology and security professionals to  constantly challenge the expectations of security solution coverage and adherence to controls to keep data and systems protected.