Oracle today announced it has updated its core management platform to provide capabilities that make it easier to manage a hybrid cloud computing environment spanning millions of endpoints.
The latest release of Oracle Enterprise Manager (EM) 13c, in addition to greater scalability, also provides support for dynamic groups, dynamic runbooks, automated workload analysis, monitoring templates, event compression and other capabilities that make it easier to manage IT operations at scale.
Oracle Enterprise Manager (EM) 13c Release 5 also extends the reach of the management platform further into the realm of packaged Oracle applications and integrated hardware and software platforms such as Oracle Exadata, Oracle Database Appliance (ODA), Zero Data Loss Recovery Appliance (ZDLRA) and Private Cloud Appliance (PCA).
Oracle has also updated the compliance framework it includes with Oracle Enterprise EM to support additional regulatory requirements and refreshed the user interface for the fleet management tool provided.
Finally, the company is adding a tool that makes it easier to copy data stored within Oracle EM 13c to the Oracle Cloud Infrastructure (OCI) service. Dubbed OCI bridge, this tool copies data to an OCI object store where it is accessed by OCI services such as logging analytics and operations insights.
Mughees Minhas, vice president of product management for enterprise and cloud manageability at Oracle, said as hybrid cloud computing continues to evolve, the need for a single management platform that spans infrastructure, databases and applications is becoming more apparent.
Minhas said Oracle EM 13c is part of larger observability initiative that Oracle has embraced to provide more context across disparate services in a way that reduces the total number of tools an IT team needs to deploy and master. That effort complements a series of autonomous computing initiatives Oracle has previously launched that eliminates the need for database administrators (DBAs) to manage lower level systems administration tasks such as performance tuning. In general, Oracle is making a case for an IT world where platforms are co-managed by Oracle and internal IT teams that are focused on higher-level tasks.
As IT environments become more distributed it’s clear IT is becoming more complex to manage. The issue that IT teams need to come to terms with is to what degree can they automate management tasks that today conspire to limit the size of the IT environment any given IT team can effectively manage. DevOps teams, of course, have been ruthlessly automating application development and deployment tasks for years. That philosophy is now being extended to include a broader range of IT operations tasks being automated by vendors themselves.
Each IT team will ultimately need to decide just how many automation platforms it requires. In many cases, IT teams are now struggling to unite various islands of automation that have now emerged within their organization. Regardless of approach, however, rote tasks that once consumed hours, sometimes days to complete, are now no longer required which, theoretically at least, should leave more time to focus on more complex challenges that are getting thornier by the day.
At its online RedisConf 2021 event, Redis Labs today detailed how the company’s in-memory database will be employed to drive real-time applications that are at the core of most digital business transformation initiatives.
Yiftach Shoolman, Redis Labs CTO and co-founder, said there are four initiatives at the core of the Redis Labs effort to replace legacy databases that organizations have historically employed to drive batch-oriented application processes.
RedisRaft, which will become available with release 7.0 of the Redis database in the third quarter, provides a module based on the Raft consensus algorithm that enable multiple Redis servers to be consumed by an application as if they were one single, fault-tolerant, logical cluster. That capability will provide IT teams with the ability to distribute Redis servers closer to the point where data is being consumed by a distributed application without incurring any conflicts between databases, said Shoolman.
At the same time, Redis is extending its Active-Active technology to enable integrated data models to be deployed in a way that allows distributed applications to run as close as possible to the point where data is being created and consumed.
Finally, RediSearch is being updated to include support for indexing capabilities in JSON applications using a nested document model, while a RedisAI capability will add an inference engine for artificial intelligence (AI) applications that can be employed as a feature store through which the deployment of AI models within applications can be managed. That approach also promises to significantly increase the overall performance of AI applications, noted Shoolman.
Historically, the Redis in-memory database has been best known for the caching capabilities it provides developers. However, Shoolman noted 66% of organizations that employ the Redis database are using it for additional use cases. As microservices that are often configured with their own database become more prevalent, the adoption of an in-memory database platform should only increase, added Shoolman.
Many of those microservices are being employed within the context of a digital business transformation project. The issue that organizations are coming to terms with is most of those processes need to run in near real-time. That requirement will eventually push more organizations toward deploying a database based on a distributed database running in-memory that appears as one logical entity to an application, said Shoolman.
At its core, Redis a data store that supports structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. Among other capabilities, it includes support for built-in replication, Lua scripting, transactions and varying levels of persistence. The company claims the core Redis datastore has been downloaded 1.5 million times in the last nine years.
On top of that installed base, Redis Labs then makes available tools for deploying and managing Redis within large-scale application environments. Most recently, Redis Labs raised an additional $100 million round of financing to bring its valuation to above $2 billion. The company now claims to have more than 8,000 paying customers, with a 54% compound annual growth rate in sales for the past three years.
It’s hard to say to what degree Redis data stores might supplant legacy database platforms. However, the one thing that is certain is there are lot more databases running in memory that, in many cases, obviate the need for a traditional relational database.
Teleport announced today it has added support for databases to a security gateway, delivered as a cloud service, that is currently used to secure Linux servers and Kubernetes clusters.
Ev Kontsevoy, CEO, said Teleport intends to extend the reach of the security gateway up the entire stack of IT infrastructure that developers routinely use to remotely access databases. Initially, Teleport 6.0 adds support for open source PostgreSQL and MySQL databases.
Teleport has gained traction as an access management tool because it provides a single binary that can be easily deployed by developers to encrypt IT platforms and enforce session controls. It automatically discovers all the resources in an IT environment, along with the protocols needed to access them. Teleport also provides a unified audit log, in a JSON format, that enables IT teams to track what resources are being accessed, when and by whom.
Other features include the ability to authenticate identities via built-in single sign-on (SSO) and multi-factor capabilities, discover and see all database instances, integrate with command line interfaces (CLIs) and a set of workflows for managing privilege escalation.
Access control is becoming a bigger issue due to a number of factors. The overall IT environment is becoming more complex as the infrastructure stack required to run applications continues to grow; most IT teams continue to work from home to help combat the COVID-19 pandemic. Teleport provides a fine-grained approach to streamlining access management across servers, clusters and databases in a way that eliminates the need to rely on virtual private networks (VPNs). In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, Kontsevoy said.
That’s critical at a time when the rise of DevSecOps is pushing responsibility for security further left toward developers, Kontsevoy added. While the rate at which that transition occurs will vary widely, Kontsevoy said it’s clear developers are taking more control over access control as part of a broader effort to roll out secure applications, faster.
It may be a while before DevOps teams are able to aggregate all the access control protocols they currently employ under a single proxy. However, Kontsevoy said, the massive amount of time and effort spent managing access control today will drive DevOps teams to look for ways to automate what is currently a very manual process.
Less clear is what role cybersecurity teams might play in supervising access management. The days when a separate overlay was needed to manage access may be coming to a close.
In the meantime, it’s clear VPNs were not designed to address access management, in an era where the bulk of IT teams – and the employees they support – are working from home. More employees may be soon be heading back to the office more frequently, but it’s likely that remote work will remain prevalent. That means legacy approaches to managing remote access that were never designed to scale will becoming increasingly obsolete.
More often than not, the types of queries that use materialized views are both faster, and use fewer resources than those that are still processing queries directly to base tables. But the key to understanding the potential that materialized views bring with them involves first understanding as much about them as possible.
What is a Materialized View?
In the world of computing, a materialized view is a database object made up of any results that were obtained from a query. Note that this could be a local copy of data that is also stored in a separate remote location, or it could have been derived from a join result. Sometimes, a materialized view could even be created after a user performed an aggregate function, thus allowing it to act as a summary of that database information.
Oracle Database first made materialized views available in version 8i of their software, and it has been a part of every release since. Just a few of the environments that support materialized views include, but are not limited to, others like SQL Server, BigQuery, PostgreSQL and Sybase SQL Anywhere.
View vs. Materialized View
What’s the difference between a regular view versus a materialized view? There are a number of important things you’ll need to keep in mind.
Chief among them, the fact that a view itself is a precise type of virtual table created via the “Create View” command. As the name suggests, it collects all data obtained from any relevant query that you’ve executed. A view will always be compiled every time it is either used or accessed in any way. This is how a view is able to make sure that you’re always getting the most updated data, no matter what – it’s literally designed to do that.
If you make any changes to the data contained inside that view, it will get pushed out to the table in which it originated. Along the same lines, any changes made to that base table are automatically pushed to the view so that the same information is in both places at once.
Because of this extra step, a view will always be a bit slower than a materialized view when it comes to performance. The upside is that this really doesn’t require much in the way of storage space. But it does mean that you’ll be sacrificing a bit in terms of performance.
With a materialized view, you’re talking about a physical copy of the information contained in that original table. This means that it isn’t updated every time you interact with it – you have to go out of your way to update it manually. Or, if you’d prefer, you can have it update using pre-defined triggers.
Because of this, a materialized view is always going to respond much faster than its traditional counterpart. However, if you don’t make an effort to confirm that it has been updated, you also run the risk of retrieving stale data.
Why Use a Materialized View?
So at this point, you’re likely asking yourself, “Why use a materialized view in the first place? What can this do for me that a simple view cannot?” The key thing to understand has to do with the costs that you accrue whenever a database is queried.
Even a simple query still needs to be parsed, validated, planned, optimized and executed. In an operational sense, this equates to CPU time. This means memory usage. This even directly impacts your opportunity costs as time goes on. All of this adds up – especially as the application you’re working with continues to evolve and become more resource-intensive.
Savvy developers are always looking for a way to cut costs, and materialized views are a big part of how they’re able to do it. Remember that the results obtained are always kept in memory – meaning that they are only updated when absolutely needed. This is the opposite of what happens when you query tables or use logical views; those results are updated constantly. Therefore, using materialized views is a great way to significantly reduce your costs without impacting performance in a way that will also affect your end users.
Materialized Views Best Practices
For best results, you should always make sure that your materialized view reflects query patterns against the original table you’re working with. Don’t just create a materialized view for every iteration of a query. Instead, create one to help focus on a broader set of queries.
Likewise, if the base table you’re working with is partitioned, your materialized view may grow to a size larger than you’re comfortable with. Therefore, it should be partitioned, as well, to preserve the performance benefits it is supposed to bring with it.
Enterprises are undergoing rapid changes. Throughout the past year, companies have been pressed to learn a diversified set of technologies and methods to remain agile in a changing economy. In this digital-first world, data plays a heightened role; in tandem, so does the delivery of data and the persistence of the database layer itself.
Applying DevOps principles and automation throughout the software life cycle is critical to maintaining a high level of efficiency. As with application development, databases are not immune to the DevOps takeover. Database DevOps is a discipline that considers the processes used to automate database changes and deployments — a field growing in mindshare as databases diversify.
Seventy percent of companies now use more than one database in their stack. Many organizations now use a blend of on-premises and cloud databases. Styles are diverging, too, as non-relational databases like NoSQL gain favor, and new open-source databases emerge to fit niche circumstances. All of this means database operators may require an increased emphasis on database DevOps to handle additional complexity.
The 2021 State of Database DevOps report, conducted by Redgate, surveyed 3,200 database professionals on the general state of their DevOps adoption. The survey also inquired about database change automation and deployment and underlying database technologies. Now, five years in, the study continues to reveal shifts in practices across industries.
Below, we’ll review the report’s main takeaways to see how companies implement database DevOps in practice.
DevOps Adoption Increases Across Projects
To meet pressing digital innovation needs, DevOps has surged in importance across all industries — 74% of organizations have adopted some form of DevOps, and 26% of respondents reported applying DevOps practices across all projects — a significant uptick from previous years. The report acknowledges a slight increase in DevOps adoption among larger company sizes.
So, which DevOps practices are companies employing the most? Well, in terms of DevOps for application development, the majority of organizations (50% or above) have adopted version control, automated builds, monitoring, automated unit tests, static code analysis and semi-automated deployments in production. Only 41% of organizations surveyed have fully automated deployments to production. These methods can be viewed as a basic benchmark for modern DevOps.
The study demonstrated that in most organizations, DevOps is a communal undertaking. More respondents reported adopting a community of practice, rather than relying on individual decision makers, to disseminate DevOps strategies and direct planning. According to the report, a community of practice is a group of people that “makes decisions, provides recommendations, or is consulted.”
Lack of Skills Tops DevOps Obstacles
The pressure is on engineers to produce to meet digital transformation demands. However, organizations experiencing a developer drought may not possess the talent to introduce DevOps practices. It’s no surprise that the common obstacle hindering DevOps adoption was a “lack of appropriate skills in the team.”
Other cultural barriers to DevOps adoption include disruption of existing workflows and a lack of alignment between teams. Interestingly, a lack of executive support was cited as the lowest hurdle to DevOps adoption, indicating universal consensus on DevOps goals. If we consider what technical barriers prevent improved software delivery and operations, 41% noted insufficient automation in release processes and 39% expressed hindrances due to legacy code.
Continuous Delivery For Databases Increases
Database DevOps appears to be growing in production use too. For the purpose of this study, Database DevOps is defined as “automating the delivery of database changes.” According to the report, 51% of respondents are already automating some parts of their database deployment process.
Though growing year after year, database DevOps is nowhere near ubiquitous. Compared to DevOps in application development, database DevOps has lower overall use. For example, only 36% are implementing automated builds. And, only 22% adopt continuous delivery (CD) for all databases. Nevertheless, this could quickly change, though, as 80% of respondents are working to implement CD for database changes or have already implemented it.
Setting up a CD process for database changes could increase overall software delivery speed. The top two drivers for adopting database automation are increasing the speed of database changes and freeing up time for other work. The third top reason, minimizing application downtime, rose in rank this year — which makes sense, as the desire to create more reliable systems is an ever-present concern.
However, to reap these rewards, organizations must overcome some significant challenges, like synchronizing application and database changes and maintaining high speeds for database automation, among other concerns.
Companies increasingly use a mix of different database technologies and styles. We also see an increase in cloud and hybrid database estates.
In terms of database styles, relational databases still make up the majority of market share — 98% of respondents have at least one relational database. However, non-relational databases, like NoSQL, are gaining popularity. Forty-seven percent of database professionals have a NoSQL database in their enterprise. Interestingly, only 2% use non-relational databases exclusively, indicating it’s a niche use case.
Enterprises are now using more databases than ever before. Seventy percent of database professionals reported having more than one database in their stack. This figure rose nearly 10% since last year. Database types are multiplying too — 45% have more than one type of database. In terms of database management systems, Microsoft SQL Server holds the most use, at an 82% usage rate. Others like MySQL, Oracle, PostgreSQL, and MongoDB trail behind.
Enterprises are also increasing their use of cloud and hybrid database deployment models. Eighty percent of respondents host a cloud database, and 65% report a mix of cloud and on-premises estate.
One possible explanation for the diversified database effect is an increase in public cloud provider usage, combined with the rise of multicloud strategies. Database options are increasing as well — many free, open-source databases can cater to unique project needs.
This “polygot persistence” could also simply be a natural occurrence within large enterprises supporting many application nuances. As Martin Fowler describes, “… any decent sized enterprise will have a variety of different data storage technologies for different kinds of data.”
In summary, non-relational databases are gaining steam, cloud and hybrid database models are becoming more common, and large organizations are increasingly using multiple database types. The landscape is forecasted to diversify further, meaning database DevOps is stepping up to manage this complexity.
The report indicates a correlation between quality database Ops and overall software quality, noting that organizations that release more frequently typically deploy database changes in much less time. To achieve these goals, “… the next area for database DevOps is in the data engineering and analytics space,” writes Pramod Sadalage, director, data & DevOps, ThoughtWorks.
While it’s important to take a vendor-endorsed study with a grain of salt, it’s safe to say we will likely see more interest in database DevOps, especially as DevOps themes continue to permeate through the entire spectrum of software development and delivery.
For more information, you can download The State of Database DevOps report behind an email gate here.
It seems we are constantly barraged with, “So-and-so announced that their systems had been breached and 80,000 user records were stolen,” notices. In fact, https://haveibeenpwned.com/ lists ten billion hacked accounts.
That is no surprise. Databases exist to pool related data together. Even NoSQL type databases, which some saw as an opportunity for wildly disparate data to be gathered and analyzed, almost exclusively contain related data sets. We generally don’t want or need to correlate, say, the number of pirates in the world with annual global temperatures, for example.
One would think, with decades of experience under our belts, we would have a good solution for protecting that data. If it was a simple problem, we would. It is not.
Databases are the primary target of most attackers. After all, getting access to your user database gives them account names through which they can try and gain elevated privileges. Getting a large amount of user/credit card information gives them a revenue stream by selling them off (though it is now so common that prices on the black market have become depressed, and this isn’t really profitable, given the risk versus the reward, anymore).
And databases must, by definition, have broad access. A database does not exist in a vacuum; it exists to serve an app. For server-based databases, it almost always exists to serve multiple apps. It must be on the corporate network (even if that network is a virtual private cloud), and it must … offer up data. It has users that have greater privileges than your average customer, and is notoriously difficult to protect with strong protections like encryption.
Encryption poses problems at multiple levels. It is still a bit slow, for starters. This is the nature of the beast – if it takes X microseconds to respond to a request, encrypted data will take at a minimum X+decrypt time (regardless of where decryption occurs). If encryption is done by column, index fields cannot be encrypted (because “nZ19?SDF” is unlikely to be in the same sort order as “ford explorer”, for example) Which means some data is immediately excepted from encryption. If encryption is handled by the database system, then the time overhead exists, and the database system must send the resulting data over your network … unencrypted. I was involved in a couple of projects that required encrypted databases – the one I can vaguely talk about was putting information about your corporate network onto Android and Apple devices. Needless to say, since phones and tablets are misplaced quite often, and most have weaker security than your average laptop, we needed information about critical infrastructure to be encrypted. It was … painful. We only managed it successfully because corporate networks are finite resources, so the amount of data we needed to store was limited, and we could prove performance wasn’t going to be the issue.
So what can you do? Continue to follow attempts to adequately encrypt corporate databases. Eventually, someone will crack this problem in a way that is performant, can be debugged and reliably protects the data.
Until then, protect your databases. Use the tools we’ve talked about in this series to monitor and protect the entire network, knowing that the database is a high-profile target if someone gets in. And use the other security tools available. The major database vendors offer DBMS security tools to evaluate your current status. Some will flag weak passwords, others will monitor for injection attacks (as will development tools discussed in the first few installments of this series). Lock down interfaces to databases – by user, by IP, whatever makes the most secure, but still usable, environment for you. Set up monitors for behavior outside the bounds of normal behavior – a query of 250K records should raise a flag, for example, since the vast majority of apps will only do a subset that can be paginated. Sure, it will probably be a false positive caused by someone hand querying, but the one time it isn’t, you’ll be glad the monitor was there.
And protect your database backups – be they actual backups or a dump to test. Fewer organizations are using real, unfiltered data for testing, but it crops up in most orgs at one point or another, as testers are trying to look at issues that fake/masked data can’t replicate. For actual backups, those must be encrypted. To lose your customers to a hacker because you had an unencrypted database dump lying around, and the attacker didn’t even have to attack the DB, is downright shameful, and happens too often. Along these same lines, and this should go without saying, but it’s happened enough that I feel compelled, do not copy large chunks of your database out to an unsecured cloud storage bucket. Some vendors have addressed this issue by not allowing public unsecured buckets, but you can still do this, depending on the cloud you are using. So, don’t.
The database security market will be best served by being rolled into SIEM and/or XDR. And while I’m in full-on pundit mode, for this statement, I’ll predict that is where it is headed. Database security is as much about overall security as it is the database, so overarching systems are the best place to detect and defend from. So watch for moves in that direction. A holistic view will serve you better in the long run.
Meanwhile? Keep rocking it. Treat your data like gold, because to hackers, it really is. And, keep running the world’s business. Celebrate your successes as much – or more – than you learn from your failures.
Lightstep this week announced general availability of a Change Intelligence observability platform based on a time-series database that is capable of processing a trillion events each day.
Ben Sigelman, Lightstep’s CEO, said as IT environments become more complex, thanks to the rise of microservices and cloud-native computing platforms, existing monitoring and observability tools will not be able to keep pace with the rate of change in what have become highly dynamic IT environments.
While AIOps promises to address that complexity by employing machine learning algorithms to analyze IT environments and surface recommendations, Sigelman said there will always be the need for observability platforms that enable IT teams to discover the root cause of an issue in a way that surfaces the insights needed to fix the problem in real-time.
The Lightstep database was built by the same team that created Monarch, the globally-distributed in-memory time series database system that Google employs to monitor its applications and systems. Lightstep’s database makes it possible to collect metrics, in the form of distributed traces, at a level of scale that allows IT teams to analyze events across a distributed IT environment made up of both monolithic and microservices-based applications, said Sigelman.
Lightstep is the latest entrant in an already crowded field of observability platforms, all seeking to consolidate the wide range of monitoring tools IT teams have used for decades.
The challenge IT teams face is that each of those monitoring tools is focused on a narrow range of platforms. IT teams often lack context when an issue arises, and wind up trying to correlate reports from multiple monitoring tools in the hopes of discovering the root cause of an issue. Observability platform providers are making the case for a single platform that correlates application and infrastructure events in a way that makes it easier for IT to fix issues faster.
Observability, of course, has been a core tenet of DevOps for years. The tools for achieving that goal, however, have been cumbersome to implement and maintain using legacy application performance management (APM) platforms. Most of those platform providers, have rolled out what are positioned as next-generation observability platforms. Now, IT organizations will need to decide if they want to maintain investments in existing platforms versus moving to one of the raft of upstarts looking to dethrone APM incumbents.
The startups are counting on a massive expansion in demand for observability platforms. IT organizations have tended to limit their usage of APM platforms to mission-critical applications due to cost and the challenges associated with maintaining the agent software needed to collect metrics from each application. Modern observability platforms have automated much of the metrics collection process, while open source software promises to make metrics collection more affordable..
The challenge, of course, is that many organizations are already struggling to manage complex IT environments, and can’t necessarily wait for that open source software to mature.
DataStax announced today the general availability of the open source Stargate application programming interface (API) framework for building applications on the Cassandra database.
Ed Anuff, chief product officer at DataStax, said Stargate will make it easier for developers to use de facto standard REST API, GraphQL API, schemaless Document API or JSON to build applications that run on Cassandra.
Previously, developers had to employ a unique set of APIs to build applications for an open source database based on wide-column store architecture. That often resulted in IT teams employing Cassandra only when their applications ran into scaling issues on other platforms, said Anuff.
Stargate will now make it possible for developers to use APIs they already know to build applications that are deployed initially on Cassandra. That, Anuff said, should reduce the headaches that are encountered whenever an organization is required to move an application from one database to another.
Stargate is available for download via the Astra cloud database service, a managed instance of Cassandra provided by DataStax. Initially previewed last summer, Stargate also makes it possible to store JSON objects in Astra without any upfront modeling required to more easily prototype applications without having to pre-define schema and queries.
DataStax is clearly trying to make it easier for developers to both build applications for Cassandra and move them if required. Many developers tend to embrace document databases early on simply because they tend to be more accessible and don’t typically require a database administrator to deploy and manage. As those applications start to scale, however, it’s not uncommon for developers to have to rehost them on another platform.
In general, Anuff said database management is finally starting to be incorporated into a larger set of DevOps processes within many IT organizations. At the same time, traditional DBAs are migrating into DataOps or CloudOps engineering roles that have been created to manage data across a wide range of data stores. The days when DBAs typically identified themselves with a single type of database platform are now largely over, he said, noting IT organizations are instead moving to models where data is made available as a service regardless of where it is stored via standard APIs.
DataStax is making a case for using Cassandra as the foundation for data services because of the platform’s ability to scale those services over time.
It’s hard to say how the database platform wars will ultimately play out. Many IT teams routinely make use of a wide range of databases and data stores. Nevertheless, there is now a lot more pressure to reduce the total cost of IT, which may lead more organizations to rationalize the number and types of database platform they support.
Regardless of the database platform selected, the way data is accessed in the enterprise has utterly changed. The challenge now is conforming the processes employed to build and deploy applications to the way data is now managed.
In this interview for TechStrong TV, I am joined by strongDM CEO Elizabeth Zalman and mParticle CISO Dave Anderson. Dave shares with us how mParticle uses strongDM proxy services to rapidly enable the expanding mParticle team to access infrastructure, assets and applications necessary for mParticle to fulfill its mission to its customers.
With the rapid growth of mParticle, the company needed a solution that would allow it to onboard its new employees and locations seamlessly. strongDM gives mParticle this capability. Have a watch of the video and follow along with the transcript to find out more.
Transcript
Alan Shimel: Hey, everyone—back here for another segment on TechStrong TV. I am joined once again by my friend Liz Zalman at strongDM. Hey, Liz, how are you?
Elizabeth Zalman: Hi, Alan. I’m well, thank you.
Shimel: Good to have you back on. And joining Liz and I today, another guest, is Dave Anderson. Dave is the CISO at mParticle. Hey, Dave—welcome to TechStrong TV.
Dave Anderson: How’s it going?
Shimel: Going great. Not as great as you are. Dave’s coming at us from a sailboat today and we’re all stuck in our homes and offices, but hey, the life of a CISO—and you guys complain.
Anderson:[Laughter]
Shimel: Anyway. You know what, we—yeah, I don’t know, it’s hard to make that less glamorous, Dave, but we’ll give you the pass. Liz, for those who haven’t seen some of our previous interviews with you and the strongDM team and some of the customers, why don’t we start off, give our audience a quick background, who’s strongDM, what you guys do?
Zalman: Sure. Strong is a proxy and it lets people manage and audit access to any firewalled infrastructure—servers, databases, Kubernetes clusters, RDP, firewalled web apps, HTTP endpoints. So, essentially, instead of managing keys and creds, you give people access to strong, and then it talks to the target systems on your behalf, so you get access control and then auditing through the proxy itself.
Shimel: Everything you expect from your proxy—great.
Zalman:[Laughter]
Shimel: And it’s sort of proxy as a service, if you will, yeah?
Zalman: Yeah, there’s a portion of it that is hosted, the control plan itself, and then the rest goes through your own hardware.
Shimel: Got it. And Dave—
Zalman: Or whatever your virtual hardware is these days.
Shimel: Well, yeah—no one uses hardware. Through your own infrastructure, how’s that?
Dave, talk to us about mParticle.
Anderson: Yeah, so, mParticle is a customer data platform. So, what that means is, our customers are able to use our platform to ingest pretty much anything, any data about their customers, about the activity that’s going on on their websites and mobile apps into the mParticle platform, and then we’re able to give our customers the full control of being able to fan that out to any of our different integration partners. So, there’s that, as well as being able to do things like data quality, match identity resolution, figure out where a particular user is, what sort of ways you want—like, how they’re interacting with their particular application or whatnot.
To be honest, we have customers, like, in a bunch of different verticals, and they all use the product a little differently, and it’s—we’re continuing to grow and innovate and figure out different ways of kind of helping our customers along with their data journey.
Shimel: Excellent. And, you know, that kinda mission is just so attuned with what I think companies are looking for today, right, which is—you know, there’s so much data out there. There’s so much—you know, do you want it all, what are you gonna do with it all, what makes sense, what doesn’t make sense? But the idea of being able to access that, analyze it—hopefully, with as much automation as possible—is what it’s all about.
Of course, it also creates—as a CISO, you know this—it creates tremendous responsibilities and potential pitfalls from a security, data, access, compliance point of view. But it also, you know, to the strongDM mission of proxying through firewall to assets, whether those assets are remote workers who have to access, you know, data in the cloud or on-prem or wherever or just whether they’re remote or not, access incorporate assets, which, in your case are, in some cases, I’m gonna assume, a lot of PII kind of data.
Dave Anderson, mParticle
Anderson: Exactly.
Shimel: This is a potential security nightmare. This is what keeps CISOs up at night on their boats. So, talk to us, Dave, what is—you know, how does strongDM help you sleep better?
Anderson: So, naturally, we’re a data collection—data collection and distribution company. So, we have a lot of data, a lot of data split up into a lot of different databases, and we have to have very tight access controls for those databases. So, one of the things that strongDM gives us the capability of doing for—when any sort of support people or operations people need access to a particular database or data set within the kinda mParticle back-end, we’re able to utilize strongDM to give us the ability to have secure access to that, that is able to be tied back to the individual who’s doing the work, everything is audited, everything’s logged, we’re able to generate reports for compliance.
So, it gives us the capabilities of not having to give our, like a support person, for example, give them a direct access to the database. They have, like, a nice tool they can use, everything is integrated nicely on the desktop, and everything is integrated well with all of our identity management platforms as well.
Shimel: Excellent, excellent. So, Dave, I think we—you know, we get what you’re doing there, we get what the potential risk is. And we’ve done a few interviews—in full disclosure, we’ve done a few interviews with some of the strongDM clients in fintech and other verticals. What we haven’t done is kinda peeled back what was—I mean, using a proxy, I think a lot of our audience has probably used a proxy one way or another.
But I want to peel back now, in the case of mParticle, walk us through how you guys sort of say, “Okay, we’re gonna use strongDM.” How did you set it up? How did you deploy? How do you manage it, right? How does it give you the warm fuzzy feeling you need to know that you can sleep well at night?
Anderson: Well, to be perfectly transparent, I was—I’m pretty new at mParticle, so, I wasn’t here when—
Shimel: So, you inherited it?
Anderson: Yeah, so, I inherited it. But I actually am a pretty early strongDM customer from my last job at Greenhouse Software, and so, I’m very familiar with that aspect of it. We used it for similar purposes back then. Back at Greenhouse, we had a lot of support personnel that were—and kinda data quality engineers that were using the strongDM platform to access our databases within AWS. And similar here, we want to have—we try to keep as much, the access as restricted as possible. We believe in the principle to release privilege, and separation of duties.
Shimel: Sure.
Anderson: So, with that, we need to have our networks deeply, deeply isolated. The databases live kinda deep into the network, not even having access to the outside world. And with that, the only way to give somebody in support access to that database traditionally would have been giving them VPN into that environment and then them having to actually install the different tools and having to manage authentication and access control. And even then, what would happen is, we would also lose visibility into what they did on that database. Like, what queries did they run, what data did they see? Because it’s not even necessarily a kinda everyday type of thing for someone to have access to the data itself. We tightly, tightly control who has access to what data, and using a tool like strongDM is pretty much a requirement for that.
Shimel: Yeah. I mean, look—and I’ll try to put it in layman’s terms for our audience who maybe aren’t as familiar with this stuff. When you’re using a VPN, they call it a tunnel, right, a tunneling tool. Because really, what you’re doing is, you’re punching a tunnel through, whether it’s your firewall in your infrastructure, and it’s an encrypted tunnel at that, right? So, everything that takes place within that tunnel is encrypted.
And so, when I connected to a database via a VPN, you may see that I did connect—oh, yeah, that’s Alan’s client and he connected to the database. But in terms of what data was in that tunnel and what—you know, you really don’t, you don’t have visibility there, by its very definition, right? On purpose. It’s not a byproduct, that’s how it’s supposed to be. And you don’t—you know, you can…it’s just, that’s how it was designed.
And so, that doesn’t really play well, you know, in the areas of DLP and you wanna make sure data’s not ________, you know, taken out. It’s a problem. So, now, strongDM helps you solve that, is what you’re telling me, because now we can see, you know, it’s a proxy, but on the backside of the proxy, that goes into the firewall and into the trusted network as we used to call it 100 years ago when I was in security, right? When you go through that into the trusted network, you can still see where Liz went or Alan went or Dave went, because it’s not that tunneled, right? It’s not that encrypted tunnel through there, it’s more of the proxy. I remember when we were NAT-ing firewalls, right, a long time ago, and it was that same thing—at least I could match up this IP to that IP, the behind the firewall versus the public IP, you know, private IP, public IP. And so, you had some of that then.
Then, on top of it—look, giving people a VPN, with everything going on in COVID and remote workers, you know, and all we’re hitting, and of course they’re not just hitting your database, there’s also SaaS apps that they need to hit and everything. A VPN is—I’m not a big fan of VPNs in today’s world, if you can’t tell, okay? I just—it don’t make sense. I mean, and then, and the whole idea of VPN-ing back into a central kinda office to go back into the cloud also kinda, I mean… You know, a friend of mine, I know a guy named Jay Chaudhry who is, of course, the CEO and Founder of Zscaler—he used to rail from the very time the cloud-first started coming on the scene big, 2006-’07, he was saying back then that VPNs were, you know, the time has come, but here we are, 2020—same thing.
But, Dave, how easy was it to set up the strongDM proxy, and what kind of visibility is it giving you?
Anderson: I mean, setting up strongDM is really easy. There’s a couple of pieces of infrastructure that you put into your environment, and that would all depend on how you deploy your infrastructure. So, there’s—I’m trying to remember the exact terminology. Like, a gateway and a—what was that?
Shimel: Liz, can you help him here?
Anderson: Yeah.
Zalman: What?
Shimel: Can you help him out, here?
Zalman: I ________. I would never leave my friend hanging—never. [Cross talk]
Anderson:[Laughter] Yeah, so, you deploy that infrastructure that, basically, that sits in your network and you have, and then it talks back to the strongDM portal and so, the strongDM clients actually know who to talk to, like, what IP addresses and what databases it has access to. You go through the strongDM UI or you can use their API, depending on your preference to set up different databases and set up the credentials in there and all the users and what users have access to what databases and what roles within those databases they have access to. And then there’s a client that runs on the person’s laptop, and that client, they’re like, you’re talking locally to that client and it’s magically on the strongDM back end, like, routing everything around to the right place and makes it extremely streamlined for the end user, because they just have this little control panel down there, like, in the bottom of their screen that lets them connect to the particular database, and it’s really, really ridiculously easy to use.
Shimel: Very cool. Now, as part of the role in CISO, you’ve always gotta be thinking not if, but when we have an incident, right? I’ve gotta be able to do forensics, I’ve gotta have an audit trail, right, I’ve gotta be able to figure out, what the heck—I have to show people what happened here, did we take reasonable steps, right, and stuff like that.
What is it, in terms of audit trail and forensics, how does strongDM help you there?
Anderson: So, it shows us who connected to what resource when, how long they were connected, what they did, what sort of careers they were in, what sort of other kinda SQL comments or whatever the database may be, and be able to produce that in near real-time, as well as have logs to go back to if there was an incident that we would know what data was accessed by a particular individual.
Shimel: So, that’s kinda the control plane that sits in the cloud, Liz, or that’s local to the client?
Zalman: The auditing happens through the gateway. So, when the request hits the gateway, it actually deconstructs it in order to provide the audit trail—so, that stays resident in Dave’s network, yeah.
Shimel: Excellent. So, we don’t have to worry about access to strangers to that.
Zalman: Yeah, no, it’s his data. We don’t wanna touch it. [Laughter]
Anderson: Yeah, that’s one of the most attractive things, actually, was the fact that the data stays in our network. strongDM operates the, how things actually get connected, but as far as, like, once you’re in that network, it’s, everything stays within there.
Zalman: Cool. Alright, sounds great. Dave, one other question. With COVID and everybody working remote, I know—look, I mean, strongDM, from what I’ve seen, has built a…not built, but while there are plenty of people, obviously, suffering as a result of COVID and my heart goes out, I’m sure as you guys, too, to people who have lost loved ones and are sick and have lost jobs and money and all of the bad things that are happening with this. The fact is, you know, with remote workers being more and more common, solutions like a strongDM are thriving, right? Are being rapidly adopted. Not because they’re nice to have, because you gotta have something like that, right? So, I’m wondering, what are you guys seeing at mParticle and a similar kind of thing as you’re going remote?
Anderson: Yeah. I mean, thankfully, we were really well-equipped for going remote. A lot of the engineering team is distributed to begin with. We had people in Seattle, Florida, Texas, and New York, of course. But we were able to transition to it pretty seamlessly. We just spend a lot more time on Zoom.
Shimel: Don’t we all?
Anderson: Yeah. [Laughter] Yes, but having the technology in place for being able to securely connect to remote networks, remote resources is definitely, it’s a requirement nowadays. I mean, especially with—you can’t, you don’t have a perimeter anymore. There isn’t that network, the whole concept of having that network firewall that was sitting there and protecting everything is kinda dead now, especially with, since everybody’s working from home. I mean, and VPNs, as we were talking about before, only give you so much. There’s only so much flexibility you have with how you can protect your network and segment your network to make a VPN be as flexible as a platform like strongDM.
Shimel: Look, I thought network firewalls were dead in 2007, right? I remember the first time I saw a Jericho—I don’t know if you remember this, Dave, but do you remember the Jericho project? Did you ever hear of that? That, you know, they were the first ones to talk about the de-perimeterization of security and micro-perimeters and personal perimeter and all that stuff. That whole moat and castle setup that the network firewall played in and the VPN was sort of a bastardized child of, you know, that disappeared when we got mobile devices and people started going mobile. Sounds like a Who song—“Going mobile, mobile”—anyway. But yeah, I don’t disagree with you.
Liz, let me ask you. I mean, mParticle, is this sort of the—it seems like it’s right in the sweet spot for what you guys are doing, then, right? This is the mission.
Zalman: This is the mission, yeah, and it’s, and actually, Dave, shifting from—I mean, what do you call Greenhouse, ATS?
Anderson: Yeah.
Zalman: It’s a form of data management, actually, shifting into customer data. It’s a vertical that I hold dear, because I actually started my career in ad tech, and what he’s describing is what I wanted a decade ago. So, like, I personally love the fact that mParticle is a customer. [Laughter] There is simply no place to store that stuff and then to link it across various touchpoints—it never came to fruition.
But yeah, a company that is distributed, that isn’t hyper-growth, it has large corporate clients who have, I’m guessing—Dave, tell me if I’m wrong—contractual requirements with respect to security and pen testing in various attestations.
Anderson: Of course, yeah.
Zalman: Yeah. [Laughter] Yeah, we do a good business in that area, and it hits all those things.
Shimel: Very cool. Guys, we’re about out of time. Dave, I appreciate you taking time out of your busy day on the boat to join us here. [Laughter] All kidding aside, man, it actually is a very great socially distanced way to get work done.
Anderson: Yeah.
Shimel: Truth be told, I’m supposed to be on a boat tomorrow and I canceled, because I had some stuff come up, and [Cross talk].
Zalman: Alan, it’s not that strongDM helps Dave sleep better at night, it’s those waves in the harbor, too. [Laughter]
Anderson:[Laughter]
Shimel: Yeah, well, that—right, they’ll help you sleep, either way. They’ll help you sleep well, as well.
Anderson: Yeah.
Shimel: I’m not gonna go there, though, Liz. You know, leave Dave alone.
Anderson: It’s also my alarm clock in the morning. [Laughter]
Zalman:[Laughter]
Shimel: Yeah, that’s exactly it. You know what, alright, the guy’s on a boat, there’s worse things. It doesn’t make him a spoiled person. I don’t wanna get—you know what, but for all those people who say CISOs are underworked and overpaid, as Dave’s living here on the boat, that’s not true. CISOs are overworked and underpaid.
But anyway—Liz, thanks for joining us.
Zalman: Thanks, Alan.
Shimel: We’ll hopefully have another interview with you soon, maybe.
Zalman: I think we have one on Friday.
Shimel: Very cool. Dave, thank you for joining us—great, continued success with mParticle. Sounds like a great business and a great use case here for strongDM, and enjoy—enjoy your time. Stay safe and stay well.
Zalman: Thank you for having me.
Shimel: Thank you. Hey, this is Alan Shimel. You just watched another TechStrong TV segment. We’re gonna be right back with another guest.
Oracle today unfurled as standalone Autonomous JSON Database service that it will manage on behalf of developers that require a document database.
Gerald Venzl, a developer evangelist and distinguished product manager for Oracle, said the Autonomous JSON Database service is based on support for JSON data types that Oracle currently provides in its Autonomous Database service based on its relational database.
Priced at a quarter of Oracle Autonomous Database service, Oracle is also targeting rivals such as MongoDB by also pricing Autonomous JSON Database service at roughly 30% less than rival managed database service, Venzl noted.
In addition, because Autonomous JSON Database service is based on the same platform Oracle employs to deliver its Autonomous Database Service, developers can add support for a wide variety of other data types by upgrading to the Autonomous Database Service with a single click, added Venzl.
That approach provides developers with more flexibility should their data requirements change, or they simply initially chose the wrong type of database for their application, said Venzl.
Other capabilities provided by the Autonomous JSON Database include support for built-in machine learning algorithms and spatial queries; fine-grained access controls; a server-side procedural language; low-code development tools; support for ACID-compliant transactions with no time or transaction size limits, support for cross-collection joins and/or aggregations and a search index for JSON documents.
Oracle also makes available an open source document store application programming interface (API) dubbed Simple Oracle Document Access (SODA) that makes it simpler for developers to employ programming languages such as Java, JavaScript and Python to build applications on top of a JSON data store. Autonomous JSON Database stores JSON documents in a native tree-oriented binary format that Oracle claims is optimized for fast reads simplified updates.
It’s not clear to what degree IT organizations will embrace managed database services. Oracle is making a case for managed database services that essentially eliminates the need to rely on database administrators to manage the infrastructure the database is deployed on as well as any upgrades made to the database itself.
Developers in recent years have embraced document databases in part because they are easier for them to provision. In most cases, developers download a document database that they at least initially manage themselves. The challenge IT organizations inevitably encounter is the number of document databases that need to be supported grows rapidly. Developers who are focused on building applications don’t always have the time required to manage fleets of databases.
Oracle is, of course, making a case of managing a variety of classes of databases. As enterprise applications continue to evolve in organizations the number of data types organizations are supporting continues to expand. A managed service focused on only one class of database may not be as appealing as a suite of managed service options.
Regardless of approach, it’s clear database management is getting more automated. The opportunity and challenge now are finding the best way to incorporate database management with a larger set of DevOps practices.
