microservices
Auto Added by WPeMatico
Tyk raises $35M for its open source, open-ended approach to enterprise API management
APIs are the grease turning the gears and wheels for many organizations’ IT systems today, but as APIs grow in number and use, tracking how they work (or don’t work) together can become complex and potentially critical if something goes awry. Now, a startup that has built an innovative way to help with this is announcing some funding after getting traction with big enterprises adopting its approach.
Tyk, which has built a way for users to access and manage multiple internal enterprise APIs through a universal interface by way of GraphQL, has picked up $35 million, an investment that it will be using both for hiring and to continue enhancing and expanding the tools that it provides to users. Tyk has coined a term describing its approach to managing APIs and the data they produce — “universal data graph” — and today its tools are being used to manage APIs by some 10,000 businesses, including large enterprises like Starbucks, Societe Generale and Domino’s.
Scottish Equity Partners led the round, with participation also from MMC Ventures — its sole previous investor from a round in 2019 after boostrapping for its first five years. The startup is based out of London but works in a very distributed way — one of the co-founders is living in New Zealand currently — and it will be hiring and growing based on that principle, too. It has raised just over $40 million to date.
Tyk (pronounced like “tyke”, meaning small/lively child) got its start as an open source side project first for co-founder Martin Buhr, who is now the company’s CEO, while he was working elsewhere, as a “load testing thing,” in his words.
The shifts in IT toward service-oriented architectures, and building and using APIs to connect internal apps, led him to rethink the code and consider how it could be used to control APIs. Added to that was the fact that as far as Buhr could see, the API management platforms that were in the market at the time — some of the big names today include Kong, Apigee (now a part of Google), 3scale (now a part of RedHat and thus IBM), MuleSoft (now a part of Salesforce) — were not as flexible as his needs were. “So I built my own,” he said.
It was built as an open source tool, and some engineers at other companies started to use it. As it got more attention, some of the bigger companies interested in using it started to ask why he wasn’t charging for anything — a sure sign as any that there was probably a business to be built here, and more credibility to come if he charged for it.
“So we made the gateway open source, and the management part went into a licensing model,” he said. And Tyk was born as a startup co-founded with James Hirst, who is now the COO, who worked with Buhr at a digital agency some years before.
The key motivation behind building Tyk has stayed as its unique selling point for customers working in increasingly complex environments.
“What sparked interest in Tyk was that companies were unhappy with API management as it exists today,” Buhr noted, citing architectures using multiple clouds and multiple containers, creating more complexity that needed better management. “It was just the right time when containerization, Kubernetes and microservices were on the rise… The way we approach the multi-data and multi-vendor cloud model is super flexible and resilient to partitions, in a way that others have not been able to do.”
“You engage developers and deliver real value and it’s up to them to make the choice,” added Hirst. “We are responding to a clear shift in the market.”
One of the next frontiers that Tyk will tackle will be what happens within the management layer, specifically when there are potential conflicts with APIs.
“When a team using a microservice makes a breaking change, we want to bring that up and report that to the system,” Buhr said. “The plan is to flag the issue and test against it, and be able to say that a schema won’t work, and to identify why.”
Even before that is rolled out, though, Tyk’s customer list and its growth speak to a business on the cusp of a lot more.
“Martin and James have built a world-class team and the addition of this new capital will enable Tyk to accelerate the growth of its API management platform, particularly around the GraphQL focused Universal Data Graph product that launched earlier this year,” said Martin Brennan, a director at SEP, in a statement. “We are pleased to be supporting the team to achieve their global ambitions.”
Keith Davidson, a partner at SEP, is joining the Tyk board as a non-executive director with this round.
Powered by WPeMatico
VCs are betting big on Kubernetes: Here are 5 reasons why
I worked at Google for six years. Internally, you have no choice — you must use Kubernetes if you are deploying microservices and containers (it’s actually not called Kubernetes inside of Google; it’s called Borg). But what was once solely an internal project at Google has since been open-sourced and has become one of the most talked about technologies in software development and operations.
For good reason. One person with a laptop can now accomplish what used to take a large team of engineers. At times, Kubernetes can feel like a superpower, but with all of the benefits of scalability and agility comes immense complexity. The truth is, very few software developers truly understand how Kubernetes works under the hood.
I like to use the analogy of a watch. From the user’s perspective, it’s very straightforward until it breaks. To actually fix a broken watch requires expertise most people simply do not have — and I promise you, Kubernetes is much more complex than your watch.
How are most teams solving this problem? The truth is, many of them aren’t. They often adopt Kubernetes as part of their digital transformation only to find out it’s much more complex than they expected. Then they have to hire more engineers and experts to manage it, which in a way defeats its purpose.
Where you see containers, you see Kubernetes to help with orchestration. According to Datadog’s most recent report about container adoption, nearly 90% of all containers are orchestrated.
All of this means there is a great opportunity for DevOps startups to come in and address the different pain points within the Kubernetes ecosystem. This technology isn’t going anywhere, so any platform or tooling that helps make it more secure, simple to use and easy to troubleshoot will be well appreciated by the software development community.
In that sense, there’s never been a better time for VCs to invest in this ecosystem. It’s my belief that Kubernetes is becoming the new Linux: 96.4% of the top million web servers’ operating systems are Linux. Similarly, Kubernetes is trending to become the de facto operating system for modern, cloud-native applications. It is already the most popular open-source project within the Cloud Native Computing Foundation (CNCF), with 91% of respondents using it — a steady increase from 78% in 2019 and 58% in 2018.
While the technology is proven and adoption is skyrocketing, there are still some fundamental challenges that will undoubtedly be solved by third-party solutions. Let’s go deeper and look at five reasons why we’ll see a surge of startups in this space.
Containers are the go-to method for building modern apps
Docker revolutionized how developers build and ship applications. Container technology has made it easier to move applications and workloads between clouds. It also provides as much resource isolation as a traditional hypervisor, but with considerable opportunities to improve agility, efficiency and speed.
Powered by WPeMatico
3 questions to ask before adopting microservice architecture
As a product manager, I’m a true believer that you can solve any problem with the right product and process, even one as gnarly as the multiheaded hydra that is microservice overhead.
Working for Vertex Ventures US this summer was my chance to put this to the test. After interviewing 30+ industry experts from a diverse set of companies — Facebook, Fannie Mae, Confluent, Salesforce and more — and hosting a webinar with the co-founders of PagerDuty, LaunchDarkly and OpsLevel, we were able to answer three main questions:
- How do teams adopt microservices?
- What are the main challenges organizations face?
- Which strategies, processes and tools do companies use to overcome these challenges?
How do teams adopt microservices?
Out of dozens of companies we spoke with, only two had not yet started their journey to microservices, but both were actively considering it. Industry trends mirror this as well. In an O’Reilly survey of 1500+ respondents, more than 75% had started to adopt microservices.
It’s rare for companies to start building with microservices from the ground up. Of the companies we spoke with, only one had done so. Some startups, such as LaunchDarkly, plan to build their infrastructure using microservices, but turned to a monolith once they realized the high cost of overhead.
“We were spending more time effectively building and operating a system for distributed systems versus actually building our own services so we pulled back hard,” said John Kodumal, CTO and co-founder of LaunchDarkly.
“As an example, the things we were trying to do in mesosphere, they were impossible,” he said. “We couldn’t do any logging. Zero downtime deploys were impossible. There were so many bugs in the infrastructure and we were spending so much time debugging the basic things that we weren’t building our own service.”
As a result, it’s more common for companies to start with a monolith and move to microservices to scale their infrastructure with their organization. Once a company reaches ~30 developers, most begin decentralizing control by moving to a microservice architecture.
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there.
Large companies with established monoliths are keen to move to microservices, but costs are high and the transition can take years. Atlassian’s platform infrastructure is in microservices, but legacy monoliths in Jira and Confluence persist despite ongoing decomposition efforts. Large companies often get stuck in this transition. However, a combination of strong, top-down strategy combined with bottoms-up dev team support can help companies, such as Freddie Mac, make substantial progress.
Some startups, like Instacart, first shifted to a modular monolith that allows the code to reside in a single repository while beginning the process of distributing ownership of discrete code functions to relevant teams. This enables them to mitigate the overhead associated with a microservice architecture by balancing the visibility of having a centralized repository and release pipeline with the flexibility of discrete ownership over portions of the codebase.
What challenges do teams face?
Teams may take different routes to arrive at a microservice architecture, but they tend to face a common set of challenges once they get there. John Laban, CEO and co-founder of OpsLevel, which helps teams build and manage microservices told us that “with a distributed or microservices based architecture your teams benefit from being able to move independently from each other, but there are some gotchas to look out for.”
Indeed, the linked O’Reilly chart shows how the top 10 challenges organizations face when adopting microservices are shared by 25%+ of respondents. While we discussed some of the adoption blockers above, feedback from our interviews highlighted issues around managing complexity.
The lack of a coherent definition for a service can cause teams to generate unnecessary overhead by creating too many similar services or spreading related services across different groups. One company we spoke with went down the path of decomposing their monolith and took it too far. Their service definitions were too narrow, and by the time decomposition was complete, they were left with 4,000+ microservices to manage. They then had to backtrack and consolidate down to a more manageable number.
Defining too many services creates unnecessary organizational and technical silos while increasing complexity and overhead. Logging and monitoring must be present on each service, but with ownership spread across different teams, a lack of standardized tooling can create observability headaches. It’s challenging for teams to get a single-pane-of-glass view with too many different interacting systems and services that span the entire architecture.
Powered by WPeMatico
Temporal raises $18.75M for its microservices orchestration platform
Temporal, a Seattle-based startup that is building an open-source, stateful microservices orchestration platform, today announced that it has raised an $18.75 million Series A round led by Sequoia Capital. Existing investors Addition Ventures and Amplify Partners also joined, together with new investor Madrona Venture Group. With this, the company has now raised a total of $25.5 million.
Founded by Maxim Fateev (CEO) and Samar Abbas (CTO), who created the open-source Cadence orchestration engine during their time at Uber, Temporal aims to make it easier for developers and operators to run microservices in production. Current users include the likes of Box and Snap.
“Before microservices, coding applications was much simpler,” Temporal’s Fateev told me. “Resources were always located in the same place — the monolith server with a single DB — which meant developers didn’t have to codify a bunch of guessing about where things were. Microservices, on the other hand, are highly distributed, which means developers need to coordinate changes across a number of servers in different physical locations.”
Those servers could go down at any time, so engineers often spend a lot of time building custom reliability code to make calls to these services. As Fateev argues, that’s table stakes and doesn’t help these developers create something that builds real business value. Temporal gives these developers access to a set of what the team calls “reliability primitives” that handle these use cases. “This means developers spend far more time writing differentiated code for their business and end up with a more reliable application than they could have built themselves,” said Fateev.
Temporal’s target use is virtually any developer who works with microservices — and wants them to be reliable. Because of this, the company’s tool — despite offering a read-only web-based user interface for administering and monitoring the system — isn’t the main focus here. The company also doesn’t have any plans to create a no-code/low-code workflow builder, Fateev tells me. However, since it is open-source, quite a few Temporal users build their own solutions on top of it.
The company itself plans to offer a cloud-based Temporal-as-a-Service offering soon. Interestingly, Fateev tells me that the team isn’t looking at offering enterprise support or licensing in the near future. “After spending a lot of time thinking it over, we decided a hosted offering was best for the open-source community and long-term growth of the business,” he said.
Unsurprisingly, the company plans to use the new funding to improve its existing tool and build out this cloud service, with plans to launch it into general availability next year. At the same time, the team plans to say true to its open-source roots and host events and provide more resources to its community.
“Temporal enables Snapchat to focus on building the business logic of a robust asynchronous API system without requiring a complex state management infrastructure,” said Steven Sun, Snap Tech Lead, Staff Software Engineer. “This has improved the efficiency of launching our services for the Snapchat community.”
Powered by WPeMatico
How Roblox completely transformed its tech stack
Picture yourself in the role of CIO at Roblox in 2017.
At that point, the gaming platform and publishing system that launched in 2005 was growing fast, but its underlying technology was aging, consisting of a single data center in Chicago and a bunch of third-party partners, including AWS, all running bare metal (nonvirtualized) servers. At a time when users have precious little patience for outages, your uptime was just two nines, or less than 99% (five nines is considered optimal).
Unbelievably, Roblox was popular in spite of this, but the company’s leadership knew it couldn’t continue with performance like that, especially as it was rapidly gaining in popularity. The company needed to call in the technology cavalry, which is essentially what it did when it hired Dan Williams in 2017.
Williams has a history of solving these kinds of intractable infrastructure issues, with a background that includes a gig at Facebook between 2007 and 2011, where he worked on the technology to help the young social network scale to millions of users. Later, he worked at Dropbox, where he helped build a new internal network, leading the company’s move away from AWS, a major undertaking involving moving more than 500 petabytes of data.
When Roblox approached him in mid-2017, he jumped at the chance to take on another major infrastructure challenge. While they are still in the midst of the transition to a new modern tech stack today, we sat down with Williams to learn how he put the company on the road to a cloud-native, microservices-focused system with its own network of worldwide edge data centers.
Scoping the problem
Powered by WPeMatico
Kong launches Kong Konnect, its cloud-native connectivity platform
At its (virtual) Kong Summit 2020, API platform Kong today announced the launch of Kong Konnect, its managed end-to-end cloud-native connectivity platform. The idea here is to give businesses a single service that allows them to manage the connectivity between their APIs and microservices and help developers and operators manage their workflows across Kong’s API Gateway, Kubernetes Ingress and Kong Service Mesh runtimes.
“It’s a universal control plane delivery cloud that’s consumption-based, where you can manage and orchestrate API gateway runtime, service mesh runtime, and Kubernetes Ingress controller runtime — and even Insomnia for design — all from one platform,” Kong CEO and co-founder Augusto “Aghi” Marietti told me.
The new service is now in private beta and will become generally available in early 2021.
Image Credits: Kong
At the core of the platform is Kong’s new so-called ServiceHub, which provides that single pane of glass for managing a company’s services across the organization (and make them accessible across teams, too).
As Marietti noted, organizations can choose which runtime they want to use and purchase only those capabilities of the service that they currently need. The platform also includes built-in monitoring tools and supports any cloud, Kubernetes provider or on-premises environment, as long as they are Kubernetes-based.
The idea here, too, is to make all these tools accessible to developers and not just architects and operators. “I think that’s a key advantage, too,” Marietti said. “We are lowering the barrier by making a connectivity technology easier to be used by the 50 million developers — not just by the architects that were doing big grand plans at a large company.”
To do this, Konnect will be available as a self-service platform, reducing the friction of adopting the service.
Image Credits: Kong
This is also part of the company’s grander plan to go beyond its core API management services. Those services aren’t going away, but they are now part of the larger Kong platform. With its open-source Kong API Gateway, the company built the pathway to get to this point, but that’s a stable product now and it’s now clearly expanding beyond that with this cloud connectivity play that takes the company’s existing runtimes and combines them to provide a more comprehensive service.
“We have upgraded the vision of really becoming an end-to-end cloud connectivity company,” Marietti said. “Whether that’s API management or Kubernetes Ingress, […] or Kuma Service Mesh. It’s about connectivity problems. And so the company uplifted that solution to the enterprise.”
Powered by WPeMatico
Docker expands relationship with Microsoft to ease developer experience across platforms
When Docker sold off its enterprise division to Mirantis last fall, that didn’t mark the end of the company. In fact, Docker still exists and has refocused as a cloud-native developer tools vendor. Today it announced an expanded partnership with Microsoft around simplifying running Docker containers in Azure.
As its new mission suggests, it involves tighter integration between Docker and a couple of Azure developer tools including Visual Studio Code and Azure Container Instances (ACI). According to Docker, it can take developers hours or even days to set up their containerized environment across the two sets of tools.
The idea of the integration is to make it easier, faster and more efficient to include Docker containers when developing applications with the Microsoft tool set. Docker CEO Scott Johnston says it’s a matter of giving developers a better experience.
“Extending our strategic relationship with Microsoft will further reduce the complexity of building, sharing and running cloud-native, microservices-based applications for developers. Docker and VS Code are two of the most beloved developer tools and we are proud to bring them together to deliver a better experience for developers building container-based apps for Azure Container Instances,” Johnston said in a statement.
Among the features they are announcing is the ability to log into Azure directly from the Docker command line interface, a big simplification that reduces going back and forth between the two sets of tools. What’s more, developers can set up a Microsoft ACI environment complete with a set of configuration defaults. Developers will also be able to switch easily between their local desktop instance and the cloud to run applications.
These and other integrations are designed to make it easier for Azure and Docker common users to work in in the Microsoft cloud service without having to jump through a lot of extra hoops to do it.
It’s worth noting that these integrations are starting in Beta, but the company promises they should be released some time in the second half of this year.
Powered by WPeMatico
Venafi acquires Jetstack, the startup behind the cert-manager Kubernetes certificate controller
It seems that we are in the middle of a mini acquisition spree for Kubernetes startups, specifically those that can help with Kubernetes security. In the latest development, Venafi, a vendor of certificate and key management for machine-to-machine connections, is acquiring Jetstack, a U.K. startup that helps enterprises migrate and work within Kubernetes and cloud-based ecosystems, which has also been behind the development of cert-manager, a popular, open-source native Kubernetes certificate management controller.
Financial terms of the deal, which is expected to close in June of this year, have not been disclosed, but Jetstack has been working with Venafi to integrate its services and had a strategic investment from Venafi’s Machine Identity Protection Development Fund.
Venafi is part of the so-called “Silicon Slopes” cluster of startups in Utah. It has raised about $190 million from investors that include TCV, Silver Lake and Intel Capital and was last valued at $600 million. That was in 2018, when it raised $100 million, so now it’s likely Venafi is worth more, especially considering its customers include the top five U.S. health insurers, the top five U.S. airlines, the top four credit card issuers, three out of the top four accounting and consulting firms, four of the top five U.S., U.K., Australian and South African banks and four of the top five U.S. retailers.
For the time being, the two organizations will continue to operate separately, and cert-manager — which has hundreds of contributors and millions of downloads — will continue on as before, with a public release of version 1 expected in the June-July time frame.
The deal underscores not just how Kubernetes -based containers have quickly gained momentum and critical mass in the enterprise IT landscape, in particular around digital transformation, but specifically the need to provide better security services around that at speed and at scale. The deal comes just one day after VMware announced that it was acquiring Octarine, another Kubernetes security startup, to fold into Carbon Black (an acquisition it made last year).
“Nowadays, business success depends on how quickly you can respond to the market,” said Matt Barker, CEO and co-founder of Jetstack . “This reality led us to re-think how software is built and Kubernetes has given us the ideal platform to work from. However, putting speed before security is risky. By joining Venafi, Jetstack will give our customers a chance to build fast while acting securely.”
To be clear, Venafi had been offering Kubernetes integrations prior to this — and Venafi and Jetstack have worked together for two years. But acquiring Jetstack will give it direct, in-house expertise to speed up development and deployment of better tools to meet the challenges of a rapidly expanding landscape of machines and applications, all of which require unique certificates to connect securely.
“In the race to virtualize everything, businesses need faster application innovation and better security; both are mandatory,” said Jeff Hudson, CEO of Venafi, in a statement. “Most people see these requirements as opposing forces, but we don’t. We see a massive opportunity for innovation. This acquisition brings together two leaders who are already working together to accelerate the development process while simultaneously securing applications against attack, and there’s a lot more to do. Our mutual customers are urgently asking for more help to solve this problem because they know that speed wins, as long as you don’t crash.”
The crux of the issue is the sheer volume of machines that are being used in computing environments, thanks to the growth of Kubernetes clusters, cloud instances, microservices and more, with each machine requiring a unique identity to connect, communicate and execute securely, Venafi notes, with disruptions or misfires in the system leaving holes for security breaches.
Jetstack’s approach to information security came by way of its expertise in Kubernetes, developing cert-mananger specifically so that its developer customers could easily create and maintain certificates for their networks.
“At Jetstack we help customers realize the benefits of Kubernetes and cloud native infrastructure, and we see transformative results to businesses firsthand,” said Matt Bates, CTO and co-founder of Jetstack, in a statement. “We developed cert-manager to make it easy for developers to scale Kubernetes with consistent, secure, and declared-as-code machine identity protection. The project has been a huge hit with the community and has been adopted far beyond our expectations. Our team is thrilled to join Venafi so we can accelerate our plans to bring machine identity protection to the cloud native stack, grow the community and contribute to a wider range of projects across the ecosystem.” Both Bates and Barker will report to Venafi’s Hudson and join the bigger company’s executive team.
Powered by WPeMatico
Epsagon scores $16M Series A to monitor modern development environments
Epsagon, an Israeli startup that wants to help monitor modern development environments like serverless and containers, announced a $16 million Series A today.
U.S. Venture Partners (USVP), a new investor, led the round. Previous investors Lightspeed Venture Partners and StageOne Ventures also participated. Today’s investment brings the total raised to $20 million, according to the company.
CEO and co-founder Nitzan Shapira says that the company has been expanding its product offerings in the last year to cover not just its serverless roots, but also provide deeper insights into a number of forms of modern development.
“So we spoke around May when we launched our platform for microservices in the cloud products, and that includes containers, serverless and really any kind of workload to build microservices apps. Since then we have had a few significant announcements,” Shapira told TechCrunch.
For starters, the company announced support for tracing and metrics for Kubernetes workloads, including native Kubernetes, along with managed Kubernetes services like AWS EKS and Google GKE. “A few months ago, we announced our Kubernetes integration. So, if you’re running any Kubernetes workload, you can integrate with Epsagon in one click, and from there you get all the metrics out of the box, then you can set up a tracing in a matter of minutes. So that opens up a very big number of use cases for us,” he said.
The company also announced support for AWS AppSync, a no-code programming tool on the Amazon cloud platform. “We are the only provider today to introduce tracing for AppSync and that’s [an area] where people really struggle with the monitoring and troubleshooting of it,” he said.
The company hopes to use the money from today’s investment to expand the product offering further with support for Microsoft Azure and Google Cloud Platform in the coming year. He also wants to expand the automation of some tasks that have to be manually configured today.
“Our intention is to make the product as automated as possible, so the user will get an amazing experience in a matter of minutes, including advanced monitoring, identifying different problems and troubleshooting,” he said
Shapira says the company has around 25 employees today, and plans to double headcount in the next year.
Powered by WPeMatico
Google details its approach to cloud-native security
Over the years, Google’s various whitepapers, detailing how the company solves specific problems at scale, have regularly spawned new startup ecosystems and changed how other enterprises think about scaling their own tools. Today, the company is publishing a new security whitepaper that details how it keeps its cloud-native architecture safe.
The name, BeyondProd, already indicates that this is an extension of the BeyondCorp zero trust system the company first introduced a few years ago. While BeyondCorp is about shifting security away from VPNs and firewalls on the perimeter to the individual users and devices, BeyondProd focuses on Google’s zero trust approach to how it connects machines, workloads and services.
Unsurprisingly, BeyondProd is based on pretty much the same principles as BeyondCorp, including network protection at the end, no mutual trust between services, trusted machines running known code, automated and standardized change rollout and isolated workloads. All of this, of course, focuses on securing cloud-native applications that generally communicate over APIs and run on modern infrastructure.
“Altogether, these controls mean that containers and the microservices running inside can be deployed, communicate with each other, and run next to each other, securely; without burdening individual microservice developers with the security and implementation details of the underlying infrastructure,” Google explains.
Google, of course, notes that it is making all of these features available to developers through its own services like GKE and Anthos, its hybrid cloud platform. In addition, though, the company also stresses that a lot of its open-source tools also allow enterprises to build systems that adhere to the same platforms, including the likes of Envoy, Istio, gVisor and others.
“In the same way that BeyondCorp helped us to evolve beyond a perimeter-based security model, BeyondProd represents a similar leap forward in our approach to production security,” Google says. “By applying the security principles in the BeyondProd model to your own cloud-native infrastructure, you can benefit from our experience, to strengthen the deployment of your workloads, how your their communications are secured, and how they affect other workloads.”
You can read the full whitepaper here.
Powered by WPeMatico