Travis CI, the popular Berlin-based open source continuous integration service, has been acquired by Idera, a company that offers a number of SQL database management and administration tools for both on-premises and cloud applications. The move comes at a time where other continuous integration services, including the likes of Circle CI, seem to be taking […]
Travis CI, the popular Berlin-based open source continuous integration service, has been acquired by Idera, a company that offers a number of SQL database management and administration tools for both on-premises and cloud applications. The move comes at a time where other continuous integration services, including the likes of Circle CI, seem to be taking market share away from Travis CI.
Idera, which itself is owned by private equity firm TA Associates, says that Travis is complementary to its current testing tools business and that the acquisition will benefit its current customers. Idera’s other tools in its Testing Tools division are TestRail, Ranorex and Kiuwan. “We admire the business value driven by Travis CI and look forward to helping more customers achieve better and faster results,” said Suhail Malhotra, Idera’s General Manager for Travis CI .
Idera clearly wants to move into the DevOps business and continuous integration is obviously a major building block. This still feels like a bit of an odd acquisition, given that Idera isn’t exactly known for being on the leading edge of today’s technology (if it’s known at all). But Travis CI also brings 700,000 users to Idera and customers like IBM and Zendesk, so while we don’t know the cost of the acquisition, this is a big deal in the CI ecosystem.
“We are excited about our next chapter of growth with the Idera team,” said Konstantin Haase, a founder of Travis CI, in today’s announcement. “Our customers and partners will benefit from Idera’s highly complementary portfolio and ability to scale software businesses to the next level. Our goal is to attract as many users to Travis CI as possible, while staying true to our open source roots and community.”
That’s pretty much what all founders write (or what the acquiring company’s PR team writes for them), so we’ll have to see how Idera will steer Travis CI going forward.
In his blog post, Haase says that nothing will change for Travis CI users. “With the support from our new partners, we will be able to invest in expanding and improving our core product, to have Travis CI be the best Continuous Integration and Development solution for software projects out there,” he writes and also notes that the Travis CI will stay open source. “This is who we are, this is what made us successful.”
Serverless has become a big buzzword of late, and with good reason. It has the potential to completely alter how developers write code. They can simply write a series of event triggers, while letting the cloud vendor worry about providing whatever amount of compute resources are required to complete the job. It represents a huge […]
Serverless has become a big buzzword of late, and with good reason. It has the potential to completely alter how developers write code. They can simply write a series of event triggers, while letting the cloud vendor worry about providing whatever amount of compute resources are required to complete the job. It represents a huge shift in how programs are developed, but it’s been difficult to find companies who were built from the ground up using this methodology because it’s fairly new.
Blissfully, a startup that helps customers manage their Software as a Service usage inside their companies, is one company that decided to do just that. Aaron White, co-founder and CTO, says that when he was building early versions of Blissfully, he found he needed quick bursts of compute power to deliver a list of all the SaaS products an organization is using.
He figured he could set aside a bunch of servers to provide that burst of power as needed, but that would have required a ton of overhead on his part to manage. At this point, he was a lone programmer trying to prove his SaaS management idea was even possible. As he looked at the pros and cons of serverless versus traditional virtual machines, he began to see serverless as a viable approach.
What he learned along the way was that serverless offers many advantages to a company with a bursty approach like Blissfully, scaling up and down as needed. But it isn’t perfect and there are issues around management and tooling and handling the pros and cons of that scaling ability that he had to learn about on the fly, especially coming in as early as he did with this approach.
Serverless makes sense
Blissfully is a service where serverless made a lot of sense. It wouldn’t have to manage or pay for servers it wasn’t using. Nor would it have to worry about the underlying infrastructure at all. That would be up to the cloud provider, and it would only pay for the bursts as they happened.
Serverless is actually a misnomer in that it doesn’t mean that there are no servers. It actually means that you don’t have to set up a servers in order to run your program, which is a pretty mind-blowing transformation. In traditional programming you have to write your code and set up all the underlying hardware ahead of time, whether it’s in your data center or in the cloud. With serverless, you just write the code and the cloud provider handles all of that for you.
The way it works in practice is that programmers set up a series of event triggers, so when a certain thing happens, the cloud provider sees this and provides the necessary resources on demand. Most of the cloud vendors are offering this type of service, whether AWS Lambda, Azure Functions or Google Functions.
At this point, White began to think about serverless as a way of freeing him from thinking about managing and maintaining infrastructure and all that entailed. “I started thinking, let’s see how far we can take this. Can we really we do absolutely everything serverless, and if so that reduces a ton of traditional DevOps-style work you have to do in practice. There’s still plenty, but that was the thinking at the beginning,” he said.
But there were issues, especially getting into serverless as early as he did. For starters, White needed to find developers who could work in this fashion, and in 2016 when it launched there weren’t a large number of people out there with serverless skills. White said he wasn’t looking for direct experience so much as people who were curious to learn and were flexible enough to deal with new technology, regardless of how Blissfully implemented that.
Once he figured out the basics, he needed to think about how this would work structurally. “Part of the challenge is figuring out where do you draw the boundaries between different serverless functions? How do you think about how much you want to overload the capability of one function versus another? How do you want to split it up? You could go way too specific, and you can of course, go way too broad. So there’s a lot of judgement calls to be made in terms of how you want to split your code base to work in this way,” he said.
The other challenge he faced going with a serverless approach so early was a dearth of tooling around it. White found Serverless, Inc right way, which helped him with a basic framework for developing, but he lacked good logging tools and says that the company still struggles with this even now. “DevOps doesn’t go away. This is still running on a server somewhere (even if you don’t control that) and you will run into issues.” One such issue he calls a “cold start issue.”
Getting the resources right
Blissfully uses AWS Lambda, and as their customers require resources, it isn’t as though Amazon has a set of dedicated resources set aside waiting for such an event. If it needs to start servers cold, that could result in latency. To compensate for that, Blissfully runs a job that pings Lambda continually, so that it’s always ready to run the actual application, and there isn’t a lag time related to starting from scratch.
The other issue could be the opposite problem. You can scale much faster than you’re ready to deal with and that can be a problem for a small team. He says in that case, you want to put a limiter on the speed of the calls so you don’t end up spending more than you can afford, and it doesn’t scale beyond your team’s ability to manage it, “I think, in some ways, this actually accelerates you running into problems where you would normally be larger scale before you really had to think about them,” White said.
The other piece is that once Lambda gets everything going, it can move data faster than your external APIs can handle, and that could require limiters to actually slow things down. “I never had that problem in the past where I was provisioning so many computational resources that Google was yelling at me for being too fast. Being too fast for Google takes a lot of effort, but it doesn’t take a lot of effort with Lambda. When it does decide to spool up whatever resources, you can do some serious outbound damaged to other APIs.” That meant he and his team actually had to think very early on about building sophisticated rate limiting schemes.
As for costs, White estimates that his costs are much lower now that he has the service built and in place. “Our costs are so low right now, and far lower than if we had server-based infrastructure. Our computational pattern is very bursty.” That’s because it re-parses the SaaS database once a day or when the customer first signs up, and in between, usage is fairly low beyond interacting with the data.
“So for us that was perfect for serverless because I don’t really need to keep capacity around that would be pure waste.”
“Slack is down.” It’s a headline we have had blaring at TechCrunch on numerous occasions (mostly because we actually get work done when not distracted by a constant waterfall of GIFs). But Slack is not alone — issues with uptime and reliability plague modern web services, from Alexa to WhatsApp to Apple Maps. As any […]
As any software engineer can atest, web application development is extraordinarily complicated. Databases, storage services, and business logic all need to work together perfectly so that users can buy their goods or watch their films.
But what happens when one piece of that application breaks down? Today, a small outage in one AWS availability zone could cascade and knock an entire service offline, as we have seen repeatedly. Today’s developer tools are decent at spotting bugs and other logic errors, but they don’t investigate applications systematically to ask how they can respond to various crises.
That’s where Gremlin comes in. The service, founded by CEO Kolton Andrus, who designed Netflix’s failure injection service and worked with CTO Matthew Fornaciari while at Amazon, is designed to throw a monkey wrench into any application, simulating faults like storage errors, database congestion, and sudden spikes in latency. It’s tagline is “break things on purpose” (something of a rift of Facebook’s “move fast and break things”).
Resiliency is clearly on investors’ minds, since the startup announced this morning at its Chaos Conf in SF that it has raised a $18 million Series B round led by Redpoint partner Tomasz Tunguz. That’s a follow-up to a $7.5 million series A led by Index Ventures partner Mike Volpi, which was announced less than a year ago.
In addition to announcing the funding today, the company unveiled its “Application Level Fault Injection” system — a mouthful of a name, but a feature that will help DevOps engineers test systems at the application level, including most importantly serverless environments.
Andrus said in a note to TechCrunch that “This past year has been a whirlwind. We spent a lot of time educating everyone from engineers to CIOs about chaos engineering and building up the community.” He said the new funding will be used to further build out Gremlin’s engineering team.
As I wrote about in-depth a few months ago, Gremlin is pioneering a field of software development dubbed “chaos engineering.” Rather than using formal verification to test whether code is accurate and performant, chaos engineers throw deliberate and systematic errors at an application in an attempt to simulate various types of failure and find brittle parts of software programs.
That sounds easy on the surface, but extremely complicated in practice: you want to simulate an outage without actually creating an outage on a mission-critical system. Netflix wants to test whether losing a database will cause video to stop playing, without physically pulling the plug on a database and seeing if your movie is still on the TV.
Gremlin’s platform provides something of a sandbox for engineers to slowly ramp up errors, and then more importantly, ramp down errors if a breakage is detected. So a DevOps engineer can add a few milliseconds of latency to a program and see how it responds, and then add a few more.
With the rise of serverless services like AWS Lambda, the complexity around applications gets even more challenging. Now, applications aren’t just on a single instance, but individual functions could be scattered across multiple instances and potentially multiple data centers. That can save developer time and reduce costs, but it also exponentially increases the risk of something going wrong and harming an application’s reliability.
Gremlin’s new ALFI feature is designed to allow more fine-grain tuning of attacks, so that DevOps engineers can target just particular aspects of an application living in a serverless environment. It’s inspired by Andrus’ work at Netflix around Failure Injection Testing, which was a sort of successor to the company’s earlier Chaos Monkey tools.
Gremlin’s ALFI feature allows developers to simulate more fine-grained failures.
It’s these sorts of features that partly intrigued Tunguz at Redpoint, who is well-known for his thoughts on SaaS. He said in a note to TechCrunch that “In the modern cloud era — where systems are distributed, containerized, and highly ephemeral — it’s become nearly impossible to have a complete understanding of system behavior without doing the kind of proactive testing Gremlin offers.”
Gremlin’s work is to not just sell a service, but to reshape how developers think about building and testing applications. Perhaps someday all of our web services will be reliable – and then how will we get work done?
Sonatype, a cybersecurity-focused open-source company, has raised $80 million from investment firm TPG. The company said the financing will help extend its Nexus platform, which it touts as an enterprise ready repository manager and library, which among other things tracks code and helps to keep everything in the devops pipeline up-to-date and secure. It’s that […]
Sonatype, a cybersecurity-focused open-source company, has raised $80 million from investment firm TPG.
The company said the financing will help extend its Nexus platform, which it touts as an enterprise ready repository manager and library, which among other things tracks code and helps to keep everything in the devops pipeline up-to-date and secure.
It’s that kind of technology that Sonatype says can prevent another Equifax -style breach of over 147 million consumers’ data. Earlier this year, the company found over dozens of Fortune Global 100 companies that downloaded outdated and vulnerable versions of Apache Struts, which Equifax failed to patch or update.
Sonatype’s chief executive Wayne Jackson his company can help prevent those type of breaches.
“We monitor literally millions of open source commits per day,” he told TechCrunch. “Last year hundreds of billions of components were downloaded by software developers, 12 percent of which had known security defects.”
The funding will go to extend the company’s Nexus platform, Jackson said.
The company said it’s had an 81 percent increase in year-over-year sales in the first-half of the year, and 1.5 million users added to its flagship Nexus platform since January. In all, the company has more than 10 million software developers and 1,000 enterprises on Nexus worldwide.
Sonatype’s last round of funding was in 2016, led by Goldman Sachs, snagging $30 million.
Atlassian today announced the first beta of a new edition of its flagship Jira project and issue tracking tool that is meant to help ops teams handle incidents faster and more efficiently. Jira Ops integrates with tools like OpsGenie, PagerDuty, xMatters, Statuspage, Slack and others. Many teams already use these tools when their services go […]
Atlassian today announced the first beta of a new edition of its flagship Jira project and issue tracking tool that is meant to help ops teams handle incidents faster and more efficiently.
Jira Ops integrates with tools like OpsGenie, PagerDuty, xMatters, Statuspage, Slack and others. Many teams already use these tools when their services go down, but Atlassian argues that most companies currently use a rather ad hoc approach to working with them. Jira Ops aims to be the glue that keeps everybody on the same page and provides visibility into ongoing incidents.
This is obviously not the first time Atlassian is using Jira to branch out from its core developer audience. Jira Service Desk and Jira Core, for example, aim at a far broader audience. Ops, however, goes after a very specific vertical.
“Service Desk was the first step,” Jens Schumacher, Head of Software Teams at Atlassian, told me. And we were looking at what are the other verticals that we can attack with Jira.” Schumacher also noted that Atlassian built a lot of tools for its internal ops teams over the years to glue together all the different pieces that are necessary to track and manage incidents. With Jira Ops, the company is essentially turning its own playbook into a product.
In a way, though, using Jira Ops adds yet another piece to the puzzle. Schumacher, however, argues that the idea here is to have a single place to manage the process. “The is that when an incident happens, you have a central place where you can go, where you can find out everything about the incident,” he said. “You can see who has been paged and alerted; you can alert more people if you need to right from there; you know what Slack channel the incident is being discussed in.”
Unlike some of Atlassian’s other products, the company doesn’t currently have any plans to launch a self-hosted version of Jira Ops. The argument here is pretty straightforward: if your infrastructure goes down, then Jira Opes could also go do down — and then you don’t have a tool for managing that downtime.
Jira Ops is now available for free for early access beta users. The company expects to launch version 1.0 in early 2019. By then Atlassian will surely also have figured out a pricing plan, something it didn’t announce today.