Developer
Auto Added by WPeMatico
Auto Added by WPeMatico
As Kubernetes and cloud-native technologies proliferate, developers and IT have found a growing set of technical challenges they need to address, and new concepts and projects have popped up to deal with them. For instance, operators provide a way to package, deploy and manage your cloud-native application in an automated way. Kubermatic wants to take that concept a step further, and today the German startup announced KubeCarrier, a new open-source, cloud-native service management hub.
Kubermatic co-founder Sebastian Scheele says three or four years ago, the cloud-native community needed to solve a bunch of technical problems around deploying Kubernetes clusters, such as overlay networking, service meshes and authentication. He sees a similar set of problems arising today where developers need more tools to manage the growing complexity of running Kubernetes clusters at scale.
Kubermatic has developed KubeCarrier to help solve one aspect of this. “What we’re currently focusing on is how to provision and manage workloads across multiple clusters, and how IT organizations can have a service hub where they can provide those services to their organizations in a centralized way,” Scheele explained.
Scheele says that KubeCarrier provides a way to manage and implement all of this, giving organizations much greater flexibility beyond purely managing Kubernetes. While he sees organizations with lots of Kubernetes operators, he says that as he sees it, it doesn’t stop there. “We have lots of Kubernetes operators now, but how do we manage them, especially when there are multiple operators, [along with] the services they are provisioning,” he asked.
This could involve provisioning something like Database as a Service inside the organization or for external customers, while combining or provisioning multiple services, which are working on multiple levels and a need a way to communicate with each other.
“That is where KubeCarrier comes in. Now, we can help our customers to build this kind of automation around provisioning, and service capability so that different teams can provide different services inside the organization or to external customers,” he said.
As the company explains it, “KubeCarrier addresses these complexities by harnessing the Kubernetes API and Operators into a central framework allowing enterprises and service providers to deliver cloud native service management from one multi-cloud, multi-cluster hub.”
KubeCarrier is available on GitHub, and Scheele says the company is hoping to get feedback from the community about how to improve it. In parallel, the company is looking for ways to incorporate this technology into its commercial offerings, and that should be available in the next 3-6 months, he said.
Powered by WPeMatico
Harness has made a name for itself creating tools like continuous delivery (CD) for software engineers to give them the kind of power that has been traditionally reserved for companies with large engineering teams like Google, Facebook and Netflix. Today, the company announced it has acquired Drone.io, an open-source continuous integration (CI) company, marking the company’s first steps into open source, as well as its first acquisition.
The companies did not share the purchase price.
“Drone is a continuous integration software. It helps developers to continuously build, test and deploy their code. The project was started in 2012, and it was the first cloud-native, container-native continuous integration solution on the market, and we open sourced it,” company co-founder Brad Rydzewski told TechCrunch.
Drone delivers pipeline configuration information as code in a Docker container. Image: Drone.io
While Harness had previously lacked a CI tool to go with its continuous delivery tooling, founder and CEO Jyoti Bansal said this was less about filling in a hole than expanding the current platform.
“I would call it an expansion of our vision and where we were going. As you and I have talked in the past, the mission of Harness is to be a next-generation software delivery platform for everyone,” he said. He added that buying Drone had a lot of upside.”It’s all of those things — the size of the open-source community, the simplicity of the product — and it [made sense], for Harness and Drone to come together and bring this integrated CI/CD to the market.”
While this is Harness’ first foray into open source, Bansal says it’s just the starting point and they want to embrace open source as a company moving forward. “We are committed to getting more and more involved in open source and actually making even more parts of Harness, our original products, open source over time as well,” he said.
For Drone community members who might be concerned about the acquisition, Bansal said he was “100% committed” to continuing to support the open-source Drone product. In fact, Rydzewski said he wanted to team with Harness because he felt he could do so much more with them than he could have done continuing as a standalone company.
“Drone was a growing community, a growing project and a growing business. It really came down to I think the timing being right and wanting to partner with a company like Harness to build the future. Drone laid a lot of the groundwork, but it’s a matter of taking it to the next level,” he said.
Bansal says that Harness intends to also offer on the Harness platform a commercial version of Drone with some enterprise features, even while continuing to support the open source side of it.
Drone was founded in 2012. The only money it raised was $28,000 when it participated in the Alchemist Accelerator in 2013, according to Crunchbase data. The deal has closed and Rydzewski has joined the Harness team.
Powered by WPeMatico
Low-code is a hot category these days. It helps companies build workflows or simple applications without coding skills, freeing up valuable engineering resources for more important projects. Paragon, a member of the Y Combinator Winter 2020 cohort, announced a $2.5 million seed round today for its low-code application integration platform.
Investors include Y Combinator, Village Global, Global Founders Capital, Soma Capital and FundersClub.
“Paragon makes it easier for non-technical people to be able to build out integrations using our visual workflow editor. We essentially provide building blocks for things like API requests, interactions with third party APIs and conditional logic. And so users can drag and drop these building blocks to create workflows that describe business logic in their application,” says company co-founder Brandon Foo.
Foo acknowledges there are a lot of low-code workflow tools out there, but many like UIPath, Blue Prism and Automation Anywhere concentrate on robotic process automation (RPA) to automate certain tasks. He says he and co-founder Ishmael Samuel wanted to focus on developers.
“We’re really focused on how can we improve developer efficiency, and how can we bring the benefits of low code to product and engineering teams and make it easier to build products without writing manual code for every single integration, and really be able to streamline the product development process,” Foo told TechCrunch.
The way it works is you can drag and drop one of 1,200 predefined connectors for tools like Stripe, Slack and Google Drive into a workflow template, and build connectors very quickly to trigger some sort of action. The company is built on AWS serverless architecture, so you define the trigger action and subsequent actions, and Paragon handles all of the back-end infrastructure requirements for you.
It’s early days for the company. After launching in private beta in January, the company has 80 customers. It currently has six employees, including Foo, who previously co-founded Polymail, and Samuel, who was previously lead engineer at Uber. They plan to hire four more employees this year.
With both founders people of color, they definitely are looking to build a diverse team around them. “I think it’s already sort of built into our DNA. As a diverse founding team we have perhaps a broader viewpoint and perspective in terms of hiring the kind of people that we seek to work with. Of course, I think there’s always room for improvement, and so we’re always looking for new ways that we can be more inclusive in our hiring recruiting process [as we grow],” he said.
As far as raising during a pandemic, he says it’s been a crazy time, but he believes they are solving a real problem and that they can succeed in spite of the macro economic conditions of the moment.
Powered by WPeMatico
On day one of TechCrunch’s Early Stage virtual conference, Ali Partovi joined us to discuss best practices for startups looking to hire engineers.
It’s a subject that’s near and dear to his heart: Partovi is co-founder and CEO of Neo, a venture aimed at including young engineers in a community alongside seasoned industry vets. The fund includes top executives from a slew of different industry titans, including Amazon, Airbnb, Dropbox, Facebook, Google, Microsoft and Stripe.
Partovi is probably best known in the Valley for co-founding Code.org with twin brother, Hadi. The nonprofit launched in 2013 with a high-profile video featuring Mark Zuckerberg, Bill Gates and Jack Dorsey, along with a mission to make coding education more accessible to the masses.
It was a two-summer internship at Microsoft while studying at Harvard that gave Partovi an entrée into the world of tech. And while it was clearly a formative experience for the college student, he advises against prospective startup founders looking to large corporations as career launch pads.
“I spend a lot of time mentoring college students, that’s a big part of what I do at Neo,” Partovi said.
“And for anyone who wants to be a founder of a company, there’s a spectrum, from giant companies like Microsoft or Google to early-stage startups. And I would say, find the smallest point on that spectrum that you’re comfortable with, and start your career there. Maybe that’s a 100-person company or maybe for you, it’s a 500-person company. But if you start at Microsoft, it’ll be a long time before you feel comfortable doing your own startup. The skills you gain at a giant company are very valuable for getting promoted and succeeding in giant companies. They’re not often as translatable to being your own founder.”
Powered by WPeMatico
The outages at RBS, TSB and Visa left millions of people unable to deposit their paychecks, pay their bills, acquire new loans and more. As a result, the House of Commons’ Treasury Select Committee (TSC) began an investigation of the U.K. finance industry and found the “current level of financial services IT failures is unacceptable.” Following this, the Bank of England (BoE), Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA) decided to take action and set a standard for operational resiliency.
While policies can often feel burdensome and detached from reality, these guidelines are reasonable steps that any company across any industry can exercise to improve the resilience of their software systems.
The BoE standard breaks down to these five steps:
Following this process aligns with best practices in architecting resilient systems. Let’s break each of these steps down and discuss how chaos engineering can help.
The operational resilience framework recommends focusing on the services that serve external customers. While internal applications are important for productivity, this customer-first mentality is sound advice for determining a starting place for reliability efforts. While it’s ultimately up to the business to weigh the criticality of the different services they offer, the ones necessary to make payments, retrieve payments, investing or insuring against risks are all recommended priorities.
Powered by WPeMatico
When it comes to choosing a tech stack, the decisions you make today could have a cascading impact for years. On one hand you want to be cool and modern, but on the other, you want to build with technology you know — and sometimes getting to market is more important than riding the latest technology wave.
The problem is that your decisions can have consequences that result in technical debt, the concept that as you make one decision, you have to pay a debt of sorts to fix underlying structural problems in the code as the result of those decisions you made early on.
Before you start freaking out, it’s something that happens to every company and is really impossible to avoid — so you make your choices and get your product out the door.
At this week’s TechCrunch Early Stage conference, HappyFunCorp CEO and co-founder Ben Schippers and CTO Jon Evans spoke about choosing the optimal tech stack. The pair have built custom software for companies like Amazon, Samsung, WeWork and AMC, so they know a thing or two about the subject.
Image Credits: HappyFunCorp
Evans says startups must weigh several key factors when choosing a tech stack, but development speed tops the list. “The single most key thing about your tech stack is speed,” he said. “The right stack will give you the most speed, compared to the alternatives.”
But early choices have other implications. “In the medium- to long-run, you have to be conscious about running up what we call technical debt, which is really the side effects of a spaghetti nest of bad code that is tightly coupled and leads to negative side effects all over the place,” he said.
Powered by WPeMatico
Reflect, a member of the Y Combinator Summer 2020 class, is building a tool to automate website and web application testing, making it faster to get your site up and running without waiting for engineers to write testing code, or for human testers to run the site through its paces.
Company CEO and co-founder Fitz Nowlan says his startup’s goal is to allow companies to have the ease of use and convenience of manual testing, but the speed of execution of automated or code-based testing.
“Reflect is a no-code tool for creating automated tests. Typically when you change your website, or your web application, you have to test it, and you have the choice of either having your engineers build coded tests to run through and ensure the correctness of your application, or you can hire human testers to do it manually,” he said.
With Reflect, you simply teach the tool how to test your site or application by running through it once, and based on those actions, Reflect can create a test suite for you. “You enter your URL, and we load it in a browser in a virtual machine in the cloud. From there, you just use your application just like a normal user would, and by using your application, you’re telling us what is important to test,” Nowlan explained.
He adds, “Reflect will observe all of your actions throughout that whole interaction with that whole browser session. And then from those actions, it will distill that down into a repeatable machine executable test.”
Nowlan and co-founder Todd McNeal started the company in September 2019 after spending five years together at a digital marketing startup near Philadelphia, where they experienced problems with web testing first-hand.
They launched a free version of this product in April, just as we were beginning to feel the full force of the pandemic in the U.S, a point that was not lost on him. “We didn’t want to delay any longer and we just felt like, you know you got to get up there and swing the bat,” he said.
Today, the company has 20 paying customers, and he has found that the pandemic has helped speed up sales in some instances, while slowing it down in others.
He says the remote YC experience has been a positive one, and in fact he couldn’t have participated had they had to show up in California as they have families and homes in Pennsylvania. He says that the remote nature of the current program forces you to be fully engaged mentally to get the most out of the program.
“It’s just a little more mental work to prepare yourself and to have the mental energy to stay locked in for a remote batch. But I think if you can get over that initial hump, the information flow and the knowledge sharing is all the same,” he said.
He says as technical founders, the program has helped them focus on the sales and marketing side of the equation, and taught them that it’s more than building a good product. You still have to go out there and sell it to build a company.
He says his short-term goal is to get as many people as he can using the platform, which will help them refine their ability to automate the test building. For starters, that involves recording activities on-screen, but over time they plan to layer on machine learning and that requires more data.
“We’re going to focus primarily over the next six to 12 months on growing our customer base — both paid and unpaid — and I really mean that we want people to come in and create tests. Even if they [use the free product], we’re benefiting from that creation of that test,” he said.
Powered by WPeMatico
As AI and machine-learning tools become more pervasive and accessible, product and engineering teams across all types of organizations are developing innovative, AI-powered products and features. AI is particularly well-suited for pattern recognition, prediction and forecasting, and the personalization of user experience, all of which are common in organizations that deal with data.
A precursor to applying AI is data — lots and lots of it! Large data sets are generally required to train an AI model, and any organization that has large data sets will no doubt face challenges that AI can help solve. Alternatively, data collection may be “phase one” of AI product development if data sets don’t yet exist.
Whatever data sets you’re planning to use, it’s highly likely that people were involved in either the capture of that data or will be engaging with your AI feature in some way. Principles for UX design and data visualization should be an early consideration at data capture, and/or in the presentation of data to users.
Understanding how users will engage with your AI product at the start of model development can help to put useful guardrails on your AI project and ensure the team is focused on a shared end goal.
If we take the ‘”Recommended for You” section of a movie streaming service, for example, outlining what the user will see in this feature before kicking off data analysis will allow the team to focus only on model outputs that will add value. So if your user research determined the movie title, image, actors and length will be valuable information for the user to see in the recommendation, the engineering team would have important context when deciding which data sets should train the model. Actor and movie length data seem key to ensuring recommendations are accurate.
The user experience can be broken down into three parts:
Knowing what a user should see before, during and after interacting with your model will ensure the engineering team is training the AI model on accurate data from the start, as well as providing an output that is most useful to users.
Will your users know what is happening to the data you’re collecting from them, and why you need it? Would your users need to read pages of your T&Cs to get a hint? Think about adding the rationale into the product itself. A simple “this data will allow us to recommend better content” could remove friction points from the user experience, and add a layer of transparency to the experience.
When users reach out for support from a counselor at The Trevor Project, we make it clear that the information we ask for before connecting them with a counselor will be used to give them better support.
Image Credits: Trevor Project (opens in a new window)
If your model presents outputs to users, go a step further and explain how your model came to its conclusion. Google’s “Why this ad?” option gives you insight into what drives the search results you see. It also lets you disable ad personalization completely, allowing the user to control how their personal information is used. Explaining how your model works or its level of accuracy can increase trust in your user base, and empower users to decide on their own terms whether to engage with the result. Low accuracy levels could also be used as a prompt to collect additional insights from users to improve your model.
Prompting users to give feedback on their experience allows the Product team to make ongoing improvements to the user experience over time. When thinking about feedback collection, consider how the AI engineering team could benefit from ongoing user feedback, too. Sometimes humans can spot obvious errors that AI wouldn’t, and your user base is made up exclusively of humans!
One example of user feedback collection in action is when Google identifies an email as dangerous, but allows the user to use their own logic to flag the email as “Safe.” This ongoing, manual user correction allows the model to continuously learn what dangerous messaging looks like over time.
Image Credits: Google
If your user base also has the contextual knowledge to explain why the AI is incorrect, this context could be crucial to improving the model. If a user notices an anomaly in the results returned by the AI, think of how you could include a way for the user to easily report the anomaly. What question(s) could you ask a user to garner key insights for the engineering team, and to provide useful signals to improve the model? Engineering teams and UX designers can work together during model development to plan for feedback collection early on and set the model up for ongoing iterative improvement.
Accessibility issues result in skewed data collection, and AI that is trained on exclusionary data sets can create AI bias. For instance, facial recognition algorithms that were trained on a data set consisting mostly of white male faces will perform poorly for anyone who is not white or male. For organizations like The Trevor Project that directly support LGBTQ youth, including considerations for sexual orientation and gender identity are extremely important. Looking for inclusive data sets externally is just as important as ensuring the data you bring to the table, or intend to collect, is inclusive.
When collecting user data, consider the platform your users will leverage to interact with your AI, and how you could make it more accessible. If your platform requires payment, does not meet accessibility guidelines or has a particularly cumbersome user experience, you will receive fewer signals from those who cannot afford the subscription, have accessibility needs or are less tech-savvy.
Every product leader and AI engineer has the ability to ensure marginalized and underrepresented groups in society can access the products they’re building. Understanding who you are unconsciously excluding from your data set is the first step in building more inclusive AI products.
Fairness goes hand-in-hand with ensuring your training data is inclusive. Measuring fairness in a model requires you to understand how your model may be less fair in certain use cases. For models using people data, looking at how the model performs across different demographics can be a good start. However, if your data set does not include demographic information, this type of fairness analysis could be impossible.
When designing your model, think about how the output could be skewed by your data, or how it could underserve certain people. Ensure the data sets you use to train, and the data you’re collecting from users, are rich enough to measure fairness. Consider how you will monitor fairness as part of regular model maintenance. Set a fairness threshold, and create a plan for how you would adjust or retrain the model if it becomes less fair over time.
As a new or seasoned technology worker developing AI-powered tools, it’s never too early or too late to consider how your tools are perceived by and impact your users. AI technology has the potential to reach millions of users at scale and can be applied in high-stakes use cases. Considering the user experience holistically — including how the AI output will impact people — is not only best-practice but can be an ethical necessity.
Powered by WPeMatico
Startup buzz comes in waves, with a particular thesis or focus coming into vogue at certain times. Remember the short-lived boom in chat bots? That was good fun. And there was the ICO craze, which lead every startup you’ve heard of to consider the financing option for at least a weekend.
We’ve also endured the early-AI bubble, the blockchain rush and a cannabis-driven wave as well. Even subtheses can see spikes, such as the neobanking industry, say, or roboadvising. Hell, we saw minicrazes in insurtech marketplaces and OKR software this year alone.
Fads in startups are not new. Today, as venture investment tilts toward enterprise software, we’re in something of a SaaS craze. Inside of today’s SaaS surge, however, is a smaller trend that I want to explore more: no-code and low-code startups.
Largely, low-code and no-code refer to tools that allow nondevelopers to either employ little (low-code) to no code while either building logic inside of software, or full applications. Low/no-code development often features drag-and-drop interfaces (Techopedia, TechTarget), but not all low-code and no-code tools are used to build apps.
Defining the sector and its focus is difficult. PitchBook says low/no-code development platforms “expedite the creation of new applications with minimal coding requirements and offer tools for nonprogrammers.” A recent TechCrunch article by a couple of venture capitalists argued that low/no-code work is “not a category itself, but rather a shift in how users interface with software tools.”
A bit like how AI and fintech are squishy categories, low-code and no-code have a wide remit.
After talking to a number of entrepreneurs lately who built these capabilities into their startups’ applications, it appears that today founders expect the capabilities to more helpful for nondevelopers reordering logic inside apps for their own needs, instead of building whole-cloth applications.
Powered by WPeMatico
When Salesforce launched Force.com in 2007, it was the culmination of years of work to bring together a way to customize Salesforce and eventually to build applications on top of the platform. By using a set of Salesforce services, companies could take advantage of work that SFDC had already done, speeding up building time and reducing time to market. Today, the successor of Force.com is called Salesforce Platform.
But going that route didn’t come without some risk, because back in 2007 building atop a Platform as a Service (PaaS) wasn’t a common way of developing software. Even by 2012 when nCino launched its banking software solutions on Force.com, it likely raised some eyebrows by using a cloud platform as the backbone of its fintech offering.
Even though it probably took resolve, the approach worked, as evidenced this week when nCino went public — a debut that was met with a strong investor response. And nCino is notably not the first time that a company built atop Salesforce’s PaaS has gone public; nCino’s own IPO follows Veeva’s 2013 debut.
But astute observers for the Salesforce ecosystem will note that other successful companies have been built on the Salesforce cloud. As you will see, many successful companies have benefited from building on top of Salesforce.
Powered by WPeMatico