Tag: data

  • How AIOps Helps You Get More Out of DevOps

    How AIOps Helps You Get More Out of DevOps

    DevOps may seem like an overused term. It involves taking an application’s source code and running it in an environment. It can cover the processes, the technology or even the people that maintain the technology that is running those very processes.

    At its heart, though, DevOps is about helping developers to be self-sufficient when it comes to the basic operations around getting their application to a real environment. Once things are running in a test or production environment, there are other IT functions that are required to keep it running and performing well. While there are teams that specialize in these functions, such as site reliability engineers (SREs) and system administration, they are usually overwhelmed by the sheer amount of data their areas of responsibility generate without considering the data that applications going through their DevOps processes are also creating.

    This is what makes AIOps the perfect complement to the DevOps space.

    What AIOps Does

    What AIOps does best is break down silos within IT. Having data from all the functional areas processed and handled by modern machine learning (ML) in a single place allows correlation, which leads to faster problem identification and resolution.

    Before machine learning was introduced, for humans to process data, more or less they operated in three ways:

    • They knew exactly what data to look for, such as when a specific business function isn’t working. There is a typical message in the monolithic application that handles all the core business.
    • They routinely sifted through data only from their area of expertise.
    • When they went outside their area, any logs and other data they had access to often was summarized data, which has time gaps and can miss a lot of detail that proper correlation needs.

    Now with ML, the AIOps data platform can perform trend analysis, look for patterns and exceptions across all the data that is being generated in the environment and highlight what it considers important through web interfaces or using an event management solution for after-hours support.

    Over time, as the AIOps platform continues to learn the environment, it can be given the ability to automatically resolve certain error conditions, as it will be able to identify them faster than human operators and often resolve them before they become service-impacting.

    How This Helps DevOps

    Machine learning aids DevOps processes in three ways when working with logs and data:

    • Knowing exactly what data to look for: In a true polyglot DevOps environment that is leveraging microservices, it is next to impossible for any one person to know the most common error messages that might occur. In this model where a new business function can be conceived, written in one of many languages, and deployed into production without Operations even being notified, ML allows the AIOps platform to quickly identify what “normal” looks like for a new microservice and start looking for anomalies.
    • Only routinely sifting through data from their area of expertise: When working in DevOps, developers need to be able to quickly find data from multiple areas in IT that is related to whatever they are trying to diagnose. Using AIOps, they will be able to quickly pull data from systems directly related to their incident. Whether it is as simple as using timecodes or a correlation GUID (globally unique identifier) that is put in the logs purposefully to aide tracking, AIOps will guide the developer through the other systems’ data.On the flip side, if there is an infrastructure problem, the same AIOps platform can help correlate what downstream services may have been impacted, from failed builds to Kubernetes pods that were restarted.
    • Summarized and incomplete data: The true value of machine learning is that it has the ability to process a higher volume and variety of data at a much higher speed and accuracy than a human, and sort and index it for later use. Not having to summarize the data to one data point every five minutes could result in a problem being discovered that has occurred often but not consistently, as it may have been dropped in the summarization.

    Conclusion

    AIOps is very young in the technology industry, but has great promise as it builds on previous generations of IT operational analytics products, combined with the latest in machine learning capabilities. DevOps is a key field in IT that has more logs than it knows what to do with. Combining the technologies and expertise in these two growth areas will have a huge positive impact on productivity across enterprises with improved service management.

    — Vince Power

  • InfluxData Video Series: Dealing with Large Amounts of Data

    InfluxData Video Series: Dealing with Large Amounts of Data

    The data deluge is becoming a daily issue, as companies collect ever more data from ever more devices and endpoints. But collecting data is one thing; deriving value from it is another.

    In this video, InfluxData VP of Products Tim Hall discusses some of the considerations in dealing with large amounts of data and how a time series database can help.

    “The vast majority of data systems that exist today are not really set up to ingest and analyze that data at speed,” he said, which can pose a real issue for organizations looking for actionable insights from their data in real-time. Time series databases enable ingestion and analysis instantly, with an ingest pipeline that allows users to gather and shape data to be useful upstream.

     

     

    To learn more, watch the video and download the “Benefits of a Purpose-Built Platform” infographic here. Also, check out the first video in the series here, the second video here and the third video here.

    — Charlene O’Hanlon

  • Using Continuous Backup to Keep Pace in an Increasingly DevOps World

    Using Continuous Backup to Keep Pace in an Increasingly DevOps World

    How continuous backup can help DevOps teams keep working with the right data

    The world of software engineering has changed; in fact it’s constantly changing. We’re moving on from the days of waterfall when big-budget releases with multiple features per version were the norm. Now, to compete, organizations have to implement agile development, with shorter release cycles and fewer improved or new features at a time. Modern software development has evolved to a practice of continuous development to the point that each new release feels like a simple patch rather than a dramatic overhaul.

    This has completely upended the testing process. Release cycles are a fraction of the time they used to be and the previous QA methods don’t stand a chance to keep pace. The latest model combines developers, operations, testing and security into close-knit teams. Development cycles are shortened and testing and deployment are automated from the source. All of this blending of teams and processes has been dubbed DevOps.

    This new paradigm for operations and development has been made possible by the flexibility ushered in by virtualization and the snapshots that can be made for a point-in-time failback. Yet, limitations remain that can keep technology from supporting the advanced needs of DevOps teams. More is still needed to keep environments up to date because once a snapshot is deleted, the data that it represented is gone.

    New tools have emerged including Docker, Kubernetes and Puppet to help on the operations side, but development teams can still be expensive if they aren’t used efficiently and effectively. Any amount of downtime or idle waiting for a database to be refreshed from production or for any sort of regression testing environments to be instantiated is burning money. DevOps processes can do this, but they aren’t effective if they don’t have a continuous stream of recovery points.

    The Quality of Code

    Development can only be as good as the copies of production data that a developer has to work with. The challenge is to get a current copy of production data in a reasonable amount of time. If it uses simulated test data designed to mimic production, results can be shoddy and defects can occur more frequently.

    A continuous backup solution with search and recovery across data, files or VMs from any point in time can make development and testing easy. Spinning up a clone of production environments is simple if you have multiple copies of data in different locations in a one-to-many configuration. Production data can then be replicated to DR facilities for protection, but also to development, test and QA environments to assure that developers and testers are working on the same, latest version of production data.

    Production replicas along with the simultaneous use of a proper API can allow the orchestration of test builds and deployments without manual intervention. This is essential because being able to perform tests on good, reliable data can significantly reduce the amount of code defects deployed into production.

    Confidence in Changes

    Because you can spin up real-time replicas of production workloads with ease, developers don’t have to guess what might happen when they push a new code update into production. Instead, the can reproduce an exact replica of production that has the latest data to an isolated area where it can’t affect production users. In this environment, they can observe the results without any risk.

    — Gijsbert Janssen van Doorn

  • Breaking Down Data Silos in Your Organization

    Breaking Down Data Silos in Your Organization

    Today’s organizations can finally use advanced technologies to unlock the true value of all of their data. This enables them to make better decisions, serve up better customer experiences, accelerate innovation and respond to crises faster—even preventing them from occurring in the first place.

    Even so, many organizations are unable to do this because their systems are too isolated from each other. Getting the most value out of your data starts with shattering data silos, or isolated “islands” of data that the majority of folks in your organization aren’t aware even exist.

    Created by the increasing use of multiple systems to store and analyze data, data silos are have become all too common in today’s organizations. Data silos create disjointed customer views that result in sub-par data analytics, which worsens the customer experience.

    Without the ability to access and analyze all of your data in a fluid manner, it becomes very difficult to deliver exemplary customer experiences and uncover what your customers truly want.

    Ridding the Data Silos

    Getting rid of data silos isn’t as hard as a lot of organizations think—in fact, there are many ways for organizations to break down data silos to make the most of their data. Here are the five best ways to break them down:

    Make it a Top Priority

    Data silos won’t get rid of themselves. If you want to eliminate data silos at your organization, make it a top priority. Develop a comprehensive plan as to how exactly you’ll get rid of them and make sure all involved employees are aware of your intentions. If necessary, put together a cross-functional team to oversee the consolidation process to ensure smoother sailing and quicker results.

    Encourage Communication and Collaboration

    Many data silos are created due to a lack of communication between teams in different departments. A marketing team, for example, might maintain a repository of content in a random Google Drive folder while sales might have a ton of assets stashed on Dropbox. Both groups might be unaware of where the other is storing their files.

    Get rid of data silos by encouraging your employees to communicate with one another regularly. It’s also important to embrace a company culture that celebrates collaboration. You’ll get better results, and the increased chatter will reduce the chances data silos go unnoticed.

    Simplify and Consolidate Tech Infrastructure

    The number of technologies requires by modern organizations to capture revenue these days is staggering. Many major organizations use more than five databases at once, with countless applications spread across them, forming an endless tangle of data silos.

    There’s an easy fix: Simplify and consolidate your tech infrastructure as much as you can. As a result, you don’t have to rely on several different databases to store, process and analyze all of your data—helping you avoid data silos.

    Avoid Costly Vendor Lock-in

    By 2020, 75 percent of organizations managing their data in a public cloud will be subject to vendor lock-in—making it costly and time-consuming to migrate data from one platform to another. Break down data silos—or avoid them in the first place—by using platforms that give you the ability to transfer this data easily.

    Develop New Processes and Procedures for Storing Data

    If your employees aren’t sure where to store data or what systems to use, can you really blame them for storing files in various locations and inadvertently creating data silos? Make sure your employees understand, very explicitly, how they are supposed to handle data and which platforms are approved. That way, you’ll reduce the chances data silos are created—while reducing or eliminating shadow IT.

    Data silos are common in businesses across all industries. The good news is that if your organization has data silos, all hope is not lost.

    By developing a plan on how to store data, encouraging employees to communicate with each other frequently and using the right tools, you can avoid data silos—making it that much easier to tap into the full power of your data.

    — Jonathan Lacefield

  • DevOps Chat: CHAOSSEARCH New Spin on Big Data Analysis

    DevOps Chat: CHAOSSEARCH New Spin on Big Data Analysis

    Analysis is the dark cloud overhanging big data — it’s difficult without the right tools. Elasticsearch by Elastic has become ubiquitous in helping organizations, but it can get unwieldy, as storage combining with compute is tricky. CHAOSSEARCH is an early stage startup designed to  make searching massive amounts of data using elasticsearch and Amazon S3 easy.

    Pete Cheslock, VP of Products at CHAOSSEARCH and a good friend of devopsy.kinsta.cloud, joined me in this DevOps Chat to discuss his latest company’s technology and how it might make big data searches less daunting. The key for big data search and analysis is separating storage from compute, using Amazon S3 and Elasticsearch.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features a returning guest to DevOps Chat. He’s actually probably been on DevOps Chat a number of times, right from I think the very beginning of when we first launched devopsy.kinsta.cloud. He’s pretty well-known in the DevOp community and really needs no introduction from me. It’s Mr. Pete Cheslock. Pete, welcome to DevOps Chat.

    Pete Cheslock: Hey, thanks a lot. Thanks for having me.

    Shimel: Yep. Pete, always a pleasure to have you, man. You know, I remember speaking with you – actually it was probably before I even launched devopsy.kinsta.cloud, up in Boston. And you kind of gave me your views on what was then a very kind of just starting to blossom DevOps community and DevOps movement. And since that time obviously a lot of water under the bridge and many different hats that you’ve worn, Pete. Here to introduce today though with your latest position in helping a company grow, and that company is called CHAOSSEARCH, correct?

    Cheslock: Yeah, that’s correct.   

    Shimel: And Pete, you’re VP of Products?

    Cheslock: Yeah, yeah, VP Products, Products, VP of Products? I don’t know, it’s a working title. We’re still trying to figure out what the best way to –

    Shimel: As long as they don’t call you a DevOps engineer, it’s all good. [Laughs]

    Cheslock: Exactly.

    Shimel: I hear ya. So Pete, well let’s start off with this. I’m going to assume a lot of people listening to this today don’t really know or are not familiar with CHAOSSEARCH, so why don’t we start with that? What’s CHAOSSEARCH?

    Cheslock: Yeah, absolutely. And yeah, I think that’s definitely a good assumption. You know, we’re an early-stage startup. We’re just going through seed funding right now, so we’re just going through an A round of fundraising, so then we’re going to be coming out to the market in a few months here. But basically what CHAOSSEARCH is is they’re trying to make it easier to access and make query-able your data as it exists on object stores. So if you think of an object store like Amazon’s S3 service. And so they developed basically a technology that allows you to store data. They basically process your data from S3 and store it back into your bucket. So what’s really interesting is they don’t hold any of your date. They’re simply – you know, you give them like a read-only to your S3 data. They’ll read in that data and shove the compressed, processed data back into your bucket. And then from there they expose APIs to allow you to access it.

    So for example, they’ll extend the S3 API to give you some really interesting capabilities of slicing and dicing your data. But the thing that they’ve exposed that’s most interesting, which got me excited about the company, is that they’ve exposed the elasticsearch APIs on top of your data on S3. And so it’s really compelling, because I spent a very long time as a really early user of elasticsearch, and it’s a great technology; it’s a great open source database. But it gets unwieldy over time. And so what really blew me away when I saw the product and what they’d built is that I can point open source log tools like Kibana to the CHAOSSEARCH APIs, accessing my own data on S3. No elasticsearch required. And so the kind of short pitch, we’re trying to make that long tail of data available to people, whether it’s log data or event data of some kind, where customers can run much smaller elasticsearch clusters of their log data or event data, and then they can essentially push the data up to S3. We’ll process it, and now they can get access to that data for weeks, months or even years.

    Shimel: Yeah. And Pete, that really highlights sort of a soft-white underbelly or a dark corner around the whole big data issue. It’s great to have – I mean, big data and – big data is only as good as the analysis we can do with it, right? That we can perform on it. And with big data we could certainly get some really keen insights to show us relationships, trends, facts that we might otherwise miss. But the dirty little secret was, for big data, to really get the value out of it, generally you needed big money kind of search to perform that kind of analysis. Because the bigger your data got, the harder it was to actually manage it, search it, analyze it. And so CHAOSSEARCH seems like a real solution for those people who are literally drowning in data.

    Cheslock: You’re exactly right. I worked at a company eight or nine years ago called Sonian, which – not a lot of people have heard of Sonian. They were one of the earliest users of Amazon’s S3 and EBS. At the time we were probably the top-three user of S3 and maybe the top-five user of EBS. What’s amazing about Sonian is the number of companies that actually came out of that place. Companies like CloudHealth, which just got acquired by VMware. Sensu was a technology that was built inside of there. Stackdriver was another one. And the reason all these startups came out of Sonian is because they were so early in the cloud space, they had to build out the technology to support it.

    One of the other ones that kind of came out on the side, not really related to us, was elasticsearch. We were trying to index customer e-mail data, like an e-mail archiving product. And so we got connected with Shay from elasticsearch before he really started the company because we were so blown away by what he had built. And elasticsearch at the time made sense, right? Using Lucene to store indexes of customer e-mail data allowed the indexes to be much smaller than the sourced e-mail files. But then over time, over the last say eight years or so, elastic’s been around, there’s been this explosion of using elasticsearch for log data. And in many cases, like structured JSON that we’re shoving into elasticsearch. And due to the inverted index nature of Lucene, the data blow up inside of Lucene where you might actually store four or five times more in disc storage on elasticsearch.

    So if you shove in a terabyte of JSON logs into your elasticsearch cluster, that could be three or four terabytes of Lucene indexes. And then you have to think about like, “Well, I want durability and reliability, so now I need to like run a replicant index.” So now you’re talking for every terabyte into elasticsearch you need like eight terabytes of physical disk. What was really amazing about what the founders and the early team here has created is the format, kind of solving for the Lucene problem. They’ve actually been able to reduce the size, yet still making the data query-able, using kind of the same APIs, which is what really blew me away, in that it’s now – you know, so many people have to make the choice. Do I keep my data for analysis, at a really high price of elasticsearch? Or, do I throw it away? And I think a lot of people just throw that data away, because they just can’t make it worthwhile in any sort of cost effective way. 

    Shimel: Right, not in an economic way. Pete, we’re far from a big data solution here at MediaOps, between our seven or eight websites, but I will tell you, just pure search, like an index search on devopsy.kinsta.cloud has become a struggle. Because a lot of the native WordPress search – you know, especially if it’s on server, is killing resources on your web server and so forth. So you want to do it sort of off-server search and it’s just a pain in the butt. Take my word for it. So this is great. You said the company’s launching in a few months though? Not that it’s launching – it’s looking for seed money now. Product will be in market. Where exactly is it now in terms of – is it in beta? Is it alpha?

    Cheslock: So yeah, we’re probably going to be closing our A fundraising round over the next 30 days or something like that. The company actually started about two and a half years ago, and so they’ve been essentially building this technology out over the past couple of years and really trying to refine it as they were kind of were coming up with this like product market fit. Like what’s the market we’re going into? And as the founders really looked at the space, they realized that log and event management is where a lot of pain is right now. What’s interesting is when people start using the product, they realize that they can process any kind of data with this and query it. And that’s where there’s a lot of interest, where maybe it’s not just log and event data. Maybe it’s like some long tail of data that you want to get access to or to monetize for your customers.

    But where we’re at right now, and what was exciting about me coming onboard is not only did my role change completely – I used to run Technical Operations for Threat Stack, which is a pretty successful cloud security company that’s still just crushing it. I changed my role over to become the Head of Product. So working with customers to understand their use cases and how they’re using tools like elasticsearch. So where we’re at right now is I’m basically looking for what we’re calling design partners, where – the best way to describe the product is in that beta phase, where we’re looking for people with really interesting datasets and maybe people who are on Amazon and have data on S3 or are using elasticsearch, and getting them into our proof of concept setup right now, where we can have them run queries, test the analysis, test how they might use it and really help us refine the final bits as we kind of _____ things up towards GA.

    And then, once we go to GA, towards – I would say October timeframe I think is what we’re aiming for, it’s really to continue to refine these really specific use cases like, “I’ve got data on S3 and I want to process this data.” We’ve had some customers that want to push their elasticsearch indices up through the service, which is a really interesting idea, because those loosing indexes already have a defined schema. And so that way, instead of storing seven days of data in elasticsearch, maybe they just store one day and that’s in their hot cluster in elasticsearch on EC2 or something. And then days two through 365 are up on S3 and are available through the CHAOSSEARCH service. So yeah, that’s kind of what the next month or two looks like for me. You know, really trying to work with customers, people with interesting datasets. You know, people who have just way too much elasticsearch and they want less of it. You know, they want to kind of run less servers, spend less money – which I feel like is kind of everyone out there right now.

    Shimel: Excellent. Very cool stuff. I mean, Pete, look, for you to get up and leave Threat Stack and come over here, obviously it had to be something really appealing and compelling, to bring you over there. Pete, it’s interesting. My background prior to devopsy.kinsta.cloud was founding and building companies, and one of the things I learned is it’s great to have these grand – come up with the idea of Docker for containers and change the way – you know, the basic platform that we use, right? For our apps and for IT. But those revolutionary kinds of things are really kind of few and far between, especially the ones that succeed. Really IT moves along in evolutionary kind of ways, where it’s a thing like this. It’s thing like with CHAOSSEARCH is doing, that makes it easier, better, faster, more economical to really get a hold of your big data and do the analysis and get a handle on it that you need to make it valuable. Right?

    Cheslock: Yeah. Exactly right.

    Shimel: And so, you know, this just feels that way to me – that this is a lot – some people may say, “Well, it’s not earthshattering.” But no, but it’s the logical step. It’s the glue that you need to – you know, big data is a big concept and it’s great and it’s going to revolutionize things when we get it. But you need the CHAOSSEARCH or sort of the glue to make these things happen, right?

    Cheslock: Yeah, what’s amazing is, as I’ve talked to people running a lot of elasticsearch, a lot of data on S3, it’s a really easy sell, because I can go to them and get them away from running these huge clusters that – they may not even take a lot of queries too. That’s what’s interesting is maybe they’re only querying their data in an automated way the last hour or 24 hours. But then you start looking out seven days, a few weeks, maybe a few months; those queries are significantly less. And so you have to either build out like a tiered storage. But at the end of the day the storage and computer are coupled so tightly that your scalable units on Amazon or any cloud provider is a lot of disk and a lot of CPA all together. And what CHAOSSEARCH has done, it uncoupled storage and compute, where the storage is on S3, specifically your S3 account, and the compute is the CHAOSSEARCH service.

    And so it’s a totally different way of thinking about, “How do I access my data? How do I make it query-able?” And now, because it costs so little – and we’re talking like go-to-market pricing a tenth of the price of running elasticsearch yourselves, and significantly less than a lot of the other kind of hosted management, log manager vendors. You know, it’s like now I can keep my data for month and a year and I can run machine learning models cost-effectively, because I can keep so much data. That’s the part that’s super interesting, is, how does this change data science and those companies that really want to have the long tail of data for ML/AI testing, and how does this change how they work their models, how they build it in? And we’re even trying to build in like tenser-flow integration into the application so that you can just access it from within without needing to have all this crazy data science experience.

    Shimel: Excellent. It really is. Pete, you know, 15 minutes goes quick. We’re coming up on our thing here. You’re VP of Product. Where do you see this going six months, a year, two years out? It’s a long way to look, but where do you see yourself taking the product direction here?

    Cheslock: Yeah, no, I always like to joke that the next six months are clear and in focus. Things get really fuzzy really quick after that. But the nice thing is I think we have a pretty clear plan going out of it. Through the end of the year, reaching GA, bringing some customers onboard that we can solve a problem for them. But really, early next year we’re going to start beta-ing a self-service kind of model, where people can come in and try it out. And probably doing even a freemium model, because since the data is in your S3 bucket and we’re just processing that data, cost is very low. So being able to provide someone a couple of gigs a day of data processing, it’s pretty easy for us. And then that way people can kind of get their feet wet and try it out and we can really start building a community around it.

    And then from there, I think the sky’s the limit. You know, we’re looking at some time end of next year, the ability to run it within your own data centers. Right now we want to be kind of pure SaaS so that we can continue and build it out and improve it in our kind of very quick, iterative development cycle. But really it’s a data platform we’re building. I mean, we’re going after that log and event management space because it’s so painful for so many people and it costs a lot of money. But the long-term for us is, what other APIs could we expose on top of your data on S3? Elasticsearch seemed to make a lot of sense, given the market. We’ve extended S3 with some interesting features. But like what else is there? What are different ways people are trying to access different data? And so I think that will be a lot of fun to kind of chat with people, understand their pain and maybe actually bring them a nice solution to that pain.

    Shimel: Yeah, absolutely. And I’m sure you’ll have a ball doing it, Pete. Anyway, we’re over time here. Pete Cheslock, newly minted VP Products, CHAOSSEARCH. Thanks for joining us on this episode of DevOps Chat, and we look forward to hearing more about CHAOSSEARCH and about your adventures, Pete.

    Cheslock: Yeah, thanks a lot. Thanks for having me. This was a lot of fun.

    Shimel: Always a pleasure. Pete Cheslock, CHAOSSEARCH. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. 

    — Alan Shimel

  • Talend Fall ’18 Enables Enterprises to Deliver Insight-Ready Data at Scale

    Major integration platform update adds advanced catalog and API development capabilities and dramatically accelerates machine learning at scale

    REDWOOD CITY, Calif. and LONDON – October 16, 2018 – Talend (NASDAQ: TLND), a global leader in cloud data integration solutions, today announced a major update to Talend Data Fabric, the company’s unified data platform for data integration across complex, multi-cloud and on-premises environments. Announced at Talend Connect UK, Talend’s Fall 2018 release delivers insight-ready data at scale with new features including Data Catalog, which creates a single source of trusted data, and Cloud Application Programming Interface (API) Services, which speeds access to standardized data for building data-as-a-service applications and increasing productivity. Talend’s new release also accelerates running machine learning algorithms at scale with extended serverless big data support.

    “Data is at the heart of digital transformation, yet the promise of data remains elusive for many companies,” said Ciaran Dynes, SVP of Products, Talend. “For businesses to survive and succeed in this ever-evolving, expanding and complex data landscape, there is a need to optimally automate every step of the data value chain and enable self-service for more data consumers. With this release, Talend helps enterprises dramatically improve how they can organize, process, and share data, which in turn enables organizations to collaborate and innovate on insight-ready data at scale.”

    “As part of our cloud-first strategy, Talend has enabled us to create a governed data lake with self-service access for business units and clients in an effort to monetize new services and generate additional revenues,” said Abderrahmane Belarfaoui, CDO, Euronext. “We compete in a highly regulated industry and face many requirements that push the processing, agility and cost of IT platforms. Using Talend, we have the confidence that our data is compliant, organized and highly sharable, with the efficiency and speed we require in order to stay ahead of the competition.”

    As part of the new Talend Data Fabric, Talend adds an API delivery platform enabling data-driven businesses to simplify data access. Talend Cloud API Services provides full API development lifecycle support from API design to test and deployment, enabling significant time savings in building and maintaining APIs. This API foundation serves as a standard and scalable way for companies to make data available to more users inside and outside an organization and to create new products and services that can drive new business models, revenue and profitability.

    “In this new era of digital transformation, nearly every organizational role is using data daily to inform decisions and actions,” said Stewart Bond, Research Director, Data Integration and Data Integrity Software, IDC. “Data cataloging software is experiencing a higher than market growth rate because it is filling a gap in the intelligence required to help organizations discover data and derive better insights to inform decisions and drive actions.”

    To organize data at scale, Talend adds new Data Catalog capabilities that enable a single source of trusted data. The Data Catalog automatically crawls all data, whether it is in a data lake, on-premises or in the cloud; profiles and classifies all the data; automatically finds and suggests relationships between data, and provides easy search-based access so end users can leverage trusted data when they need it to make immediate business decisions.

    The Fall 2018 Talend Data Fabric also accelerates running machine learning models at scale with native, extended serverless big data support for Microsoft Azure Databricks as well as Qubole in AWS cloud environments. Talend’s self-service Apache Spark processing makes it easy to spin up a cluster and control costs by just paying for what is used through serverless and spot instances. The new capabilities help to automate insight and enables businesses to process more data at lower costs.

    The comprehensive Talend Data Fabric delivers a unified platform for data integration across public, private,and hybrid cloud, as well as on-premises environments, and facilitates greater collaboration between IT and business teams. Combined with an open, native and extensible architecture for rapidly embracing market innovations, Talend enables customers to cost-effectively meet the demands of ever-increasing data volumes, users and use cases.

    The Fall 2018 update to the Talend Data Fabric will be available in November for free to customers with up-to-date paid subscriptions. For information on new features and capabilities, please visit https://www.talend.com/products/whats-new. Additionally, a webinar detailing the Fall 2018 update will take place on Nov. 8. Register here to join.

  • Database Security: Best Practices for Keeping Data Safe

    Database Security: Best Practices for Keeping Data Safe

    Database security is of utmost importance to sectors including IT, banking, finance and ecommerce. Every other transaction is based on how secure their database is, as it holds every detail including usernames, passwords, customers’ credit card information and so on.

    The term “database security” denotes a series of measures initiated by the service provider to proactively protect the information and database management software from malicious threats, phishing attacks, DoS (denial-of-service) and malware. The security is achieved by using streamlined processes, automation, security tools and trained experts who work around the clock.

    Different Levels of Database Security

    There are different levels of securing your databases, including:

    • Data Level Security: The process of protecting the data itself from getting stolen or tampered with in the servers.
    • System Level Security: Protecting networking servers, hardware and other inbound/outbound communications from acting as a funnel to distribute malicious software.
    • User Level Security: A server is always attacked from a user level, which is why organizations rely on real-time protection software to monitor transactions and also restrict the user from visiting unauthorized websites or downloads from untrusted sources.

    Most Commonly Spotted Database Attacks

    These are the most common attacks triggered that threaten database security:

    • Buffer overflow vulnerability
    • DoS attacks
    • Privilege escalation
    • Weak authentication
    • SQL injection threats

    Best Practices for Database Protection

    Experts recommend following a checklist that includes some of the most widely used and trusted methods to ensure database security:

    Physical Security

    The first method is securing physical servers using digital locks, using CCTV cameras to monitor them continuously and preventing any unauthorized entry with the help of 24/7 security services.

    Establishing Firewall for Servers

    Every connection to the database can be set by default to deny all incoming traffic using a firewall. It will also block direct client access and allow only authorized applications. The firewall rules will be strictly monitored and maintained by system administrators (SAs) and database administrators (DBAs). They will also perform network scans and ISP scans to strengthen the server machines.

    Using a Trusted Database Software

    The database software can either be open source or a paid version supported by the vendor. The software will run only on active devices while inactive devices will be unplugged and default accounts that are no longer in use will be removed periodically. Timely security patches are applied.

    It’s also important to take a close look at your software vendor to determine if they’re keeping their code as secure as possible.

    Implementing Application Code

    The DBAs will ensure all configuration files and source codes are accessible only through authorized operating system accounts. Application code is regularly reviewed to ensure it is not vulnerable to SQL injection.

    Role of SAs and DBAs

    The role of DBAs and SAs are vital, as they play the role of strict administrators. Authorization is allowed only to select people and all of them will sign an NDA along with a background check.

    DBA staff will be allowed to use individual accounts and not shared accounts to access the server. They are required to create and maintain the strongest of passwords that meet the necessary security and safety guidelines.

    Change Management and Database Auditing

    Another security measure is to keep track of change management by logging all database activities. Every bit of login data will be maintained for at least one year for security audits, and any account that faces maximum failed login attempts will automatically be notified to the database administrator to take necessary steps.

    The Triangular Concept for Database Security

    • Confidentiality: Maintaining confidentiality is enforced through encryption by encrypting both data that is being transferred and data that is stored in the database in case it gets breached.
    • Integrity: A user access control system will be in place to ensure only authorized personnel are allowed access to the data and a log is maintained of everyone who gains access to it to ensure there are not data breaches caused by internal errors.
    • Availability: The data stored should be made available to both users and administrators, which is made by reducing downtime. Servers are periodically updated for maximum security while boosting business through continuous service.

    When a database administrator is aware of the most common threats and the different methodologies that they should implement to protect data, they can be rest assured that the data stored in servers are protected to the core. Besides, they should also practice best practices in backup and data recovery to safeguard themselves against ransomware.

    — Sophie Ross

  • We Still Haven’t Solved the Logging Problem

    We Still Haven’t Solved the Logging Problem

    At a company I previously worked at, I helped build out the initial infrastructure to support a large cloud security product. It was one of the first times I had the opportunity to build something from nearly the very beginning. Like many operations professionals, so much of my career prior to this experience had been spent cleaning up other people’s messes and technical debt that I was finally excited to “do things right” from the onset.

    Looking back, I wish I knew that building our monitoring platform would be hampered without the ability to retain and analyze both warm and cold log data. Here’s why.

    Time Series to the DevOps Rescue 

    Hindsight is almost always 20/20, and today I can proudly say that my team and I built a killer app monitoring platform. My goal was to make it easy for Dev and Ops folks to report time series metrics for their applications and build dashboards and alerts for app health. And we did just that.

    While many ops colleagues would say that monitoring journeys usually start by capturing application logs with open source tools such as Logstash/Elasticsearch, Graylog2, or even buying commercial services from Splunk or Sumo Logic, not all journeys start that way. My team and I took a different approach and optimized for time series metrics versus the more traditional structured log management approach, leveraging newer toolsets such as Librato for real-time operations monitoring and performance analytics. Librato enabled us to scale much faster than with traditional log solutions and gave us almost instant visibility across our containers, cloud servers and the apps themselves.

    Logging is Too Expensive 

    Using hosted services such as Librato to manage our time series metrics worked fine for a while. However, the cost of SaaS monitoring eventually grew, and, since we had the time and energy to bring metrics in house, we deployed Graphite, the open source enterprise-grade monitoring tool. Graphite allowed us to continue enabling our engineers with affordable access to granular time series metrics to help them manage their applications.

    While this allowed the business to respond quickly when an issue arose, time series metrics were only part of the solution. They allowed us to see what was happening, but not always why it happened. While time series metrics and even some of the more advanced tracing technologies including Jaeger and Opentracing are fantastic to help debug complex distributed systems, they fall short when investigating and analyzing causes for problems, issues and hacks.

    Digging Into Your Log History Gets Expensive, Quick

    Tools such as the ELK stack have been booming, with Elastic alone hitting more than 100 million downloads last year, which shows that DevOps teams want more from traditional log management solutions. They’re looking for simplicity, ease of use and affordability, among others. With JSON effectively the de facto standard for logging, most teams take log data with its predefined schema and then index it into Elasticsearch/Lucene. Unfortunately, the Lucene indexing mechanism results in an unintended consequence: a 5 to 10X increase in disk usage. And just like that, ops cloud budgets get blown away when they realize that 10GB of JSON data indexed into Elasticsearch could be 50GB of disk used. You wanted that index to be replicated for disaster recovery as well? Then add 100GB of storage for every 10GB of logs.

    DevOps Normal: Still the Tough Choice Between Retention and Cost

    Unfortunately, most people choose to simply purge data from our “hot” Elasticsearch clusters as soon as we possibly can to minimize cost issues. This is far from ideal.

    Companies moving to microservices-based architectures, deployed on containers such as Kubernetes, are going to be in for a rude awakening when they start building out their centralized logging platforms to keep up with the volume. Security teams are going to feel the burden as well, as they come under increasing pressure to keep data around for long periods of time due to compliance and audit reasons. When the next big web-facing vulnerability comes out, the ability to go back weeks or months will be key to see what IP address accessed a potentially malicious endpoint. With that data available, we could then take all those IPs and correlate them with other access logs.

    Is centralized logging any better than it was 10 years ago? Or has all this data generated exploded so much that the tools we have today are just barely keeping up? One thing is certain, this problem is far from solved, and many companies may find themselves drowning in their own data lakes.

    — Pete Cheslock

  • How ‘Mature’ is Your Data Integration Competency?

    How ‘Mature’ is Your Data Integration Competency?

    To succeed with their digital transformation initiatives, companies need to use data to the full extent of their capability. Having the right data and applying it to the right problems can help companies gain new insights, create new models and disrupt stagnant processes. No argument there.

    The problem is, not everyone is putting their data in a position to succeed. According to analyst reports, many IT departments are behind the curve in developing processes to integrate their data, leaving them at a disadvantage when it comes to supporting their organization’s digital transformation efforts.

    Why is this happening? How big is the issue? And what can companies do about it?

    An Explosion of Data

    The why is easy to answer. Data is running wild, and society hasn’t fully figured out how to rein it in. There have been shifts in the way data is being created and consumed, forcing companies to rethink the way they integrate it and manage it on a broad scale.

    On the creation side, business data volumes are exploding, doubling nearly every year, according to some estimates. Data integration has evolved from an environment where traditional endpoints remained static to one of modern endpoints that are dynamic and constantly changing. Plus, the technology landscape itself is undergoing continuous transformation, with the regular emergence of new applications and business models.

    Data consumption is changing, too. Companies are reacting by trying to adapt integrations quickly, make changes and fixes as fast as possible, keep data secure and stable, and give more users access to the technology to avoid IT bottlenecks.

    To manage these more complex, data-driven processes, many organizations are still trying to handle integration projects by writing custom code. This is typically done to meet development efforts triggered by an immediate business need. The benefits can seem enticing: The staff can get started right away, there are no new development tools to bring on, and deployment is simple.

    But there are hidden costs to doing custom data integration. The inability to reuse code forces developers to rewrite integrations over and over. Brittle code can create a maintenance overload. When developers leave, the organization’s knowledge base breaks down. And custom work tends to address one set of business parameters, creating a lack of standardization and further duplication of work and planning.

    The Benefits of Hybrid Integration

    Using a hybrid integration model, organizations can leverage an assortment of tools to support today’s level of pervasive integration, spanning deployment models, diverse endpoints, integration domains and constituent users of integration technology. These hybrid platforms tend to include more enterprise-focused competencies ranging from prebuilt workflow templates, connectors, and automated management and maintenance capabilities.

    How equipped are today’s organizations in data integration? According to a Gartner report released earlier this year, “IT organizations struggle to meet the challenge of pervasive integration for digital business transformation.”

    In its report, “Use the Integration Maturity Model to Assess and Improve Your Integration Competency,” Gartner outlined a “five-level integration maturity model based on more than 20 years of analysis of the integration technology market and organizations’ approaches to integration. Each level is characterized by the degree of mastery of integration challenges in terms of awareness, organizational settings, technology platform use, methodology, approach and sourcing policy.” The firm estimated that 55 percent of Gartner clients (including SMBs and large enterprises) are in the “Getting Started” phase at either level 1 (ad hoc) or level 2 (enlightened)  and less than 5 percent of Gartner clients (including SMBs and large enterprises) are in the “Staying-on-Top” phase, at level 5 (plug and play).

    How can your organization evaluate and improve its integration maturity? How can you help move the needle?

    Here are a few tips to position your company better to handle data-related challenges.

    • Traditional point-to-point integration solutions typically fail due to integration complexity, error handling, divergent practices and change management. Take the time to evaluate and understand the total cost of managing and maintaining custom coded data and application integrations before you commit your highly specialized resources to the projects.
    • Evaluate the benefits of implementing a unified approach for converged data and application integration using a truly hybrid data integration platform that provides reusable integration templates that can be configured and deployed for ad-hoc and enterprise data hub use cases alike.
    • Look to the future and choose a platform that supports a variety of integration management and deployment options, and avoid cloud lock-in with iPaaS-only providers.

    Conclusion

    Integrating data isn’t easy. Data is coming from more places and used in more ways by more people than ever before. Organizations that develop strong data integration capabilities will do a better job leveraging the data they need to drive transformation projects forward in a positive way.

    — Alan Dunkin

  • DevOps Security: 3 Privileged Access Management Best Practices

    DevOps Security: 3 Privileged Access Management Best Practices

    The tremendous upside of DevOps practices and tools are enough to keep organizations pressing forward at all costs. But when sloppy use of DevOps toolchains cause breaches, more than half the time it comes down to poor protection of privileged accounts. According to a recent study by security vendor Beyond Trust, 52 percent of IT practitioners say that overprivileged users are at the root of DevOps and other next-generation technology-caused breaches.

    If organizations are going to reap the biggest benefits from DevOps without putting their IT infrastructure and data at risk, they’re going to need to think more strategically about how they handle privileged access management (PAM), said Morey Haber, CTO at Beyond Trust. devopsy.kinsta.cloud recently caught up with Haber to break down three of the most important PAM best practices for DevOps teams to build into the continuous delivery pipeline.

    Discover and Inventory All Privileged Accounts and Assets

    You can’t manage accounts and assets you don’t know about, so this step is foundational to the whole process of PAM. Unfortunately, with so many scripts and so much automation layered all over the DevOps toolchain, it can be tremendously difficult.

    “If it’s embedded in other runtimes or it’s hard-coded into compiled executables, that discovery is the hardest,” Haber said. But it must be done. Organizations need to get clear visibility into exactly what tools are executing the automation and what the privileges are assigned to them. “Is it a power-shelf script? Is it embedded in Jenkins or somewhere else? What is actually running? Who’s running it and when?”

    Additionally, organizations need to understand where the automation is stored and, consequently where that embedded credential information is being stored, so it can be examined for tamperability and safety of the credentials.

    “Now, this isn’t something that’s easy to discover in any of the three contexts, but it has to be,” Haber said. “So, one you have to understand the entire process and where you’re actually embedding privileged credentials for the edit, storage, operation and scripting itself.”

    Manage Shared Secrets and Hard-Coded Passwords

    Hard-coded passwords are one of the biggest no-nos in credential management. Unfortunately, even when application security teams are meticulous about rooting hard-coded passwords out of their finished applications, they often leave them within the IT infrastructure that helps support the development of that software for the sake of expedience. Same goes for account sharing, which is a frequent mistake organizations make to just get the automation working and keep it working with stability.

    The problem is, this trashes any semblance of traceability or auditability of activity within the affected environment.

    “Whether that is using some type of proxy technology, a VDI environment—anything, you don’t want people logging in directly with shared accounts because you can’t trace that,” Haber said, noting there needs to be a control plane in the mix that can keep track of both individual users and script or automation accounts that are impacting the environments to track each process or activity against unique credentials. This is essential not just for compliance, but for forensics and the overall integrity of a DevOps team’s software “factory.”

    Enforce the Rule of Least Privilege

    Ultimately, strong PAM depends upon only giving individual users or specific automation accounts the exact amount of privileges they need to get their job done.

    “We see credentials being given to DevOps teams all the time that are way, way overprivileged,” Haber explains “It should come down to the least privileged model—that you’re giving enough privileges for the DevOps process to work, but not overprovisioning so that if any process or account is compromised, it doesn’t jeopardize the rest of the environment.”

    — Ericka Chickowski