Log in
E-mail
Password
Remember
Forgot password ?
Become a member for free
Sign up
Sign up
New member
Sign up for FREE
New customer
Discover our services
Settings
Settings
Dynamic quotes 
OFFON

CLOUDFLARE, INC.

(NET)
  Report
Real-time Estimate Quote. Real-time Estimate Cboe BZX - 06/18 11:56:40 am
99.86 USD   -0.82%
08:58aCLOUDFLARE  : William O'Neil Starts Cloudflare at Buy
MT
06/17CLOUDFLARE  : Announcing WARP for Linux and Proxy Mode
PU
06/16CLOUDFLARE  : Building Waiting Room on Workers and Durable Objects
PU
SummaryQuotesChartsNewsRatingsCalendarCompanyFinancialsConsensusRevisions 
SummaryMost relevantAll NewsAnalyst Reco.Other languagesPress ReleasesOfficial PublicationsSector newsMarketScreener Strategies

Cloudflare : Acquires Linc

12/22/2020 | 08:15am EDT

Cloudflare has always been about democratizing the Internet. For us, that means bringing the most powerful tools used by the largest of enterprises to the smallest development shops. Sometimes that looks like putting our global network to work defending against large-scale attacks. Other times it looks like giving Internet users simple and reliable privacy services like 1.1.1.1. Last week, it looked like Cloudflare Pages - a fast, secure and free way to build and host your JAMstack sites.

We see a huge opportunity with Cloudflare Pages. It goes beyond making it as easy as possible to deploy static sites, and extending that same ease of use to building full dynamic applications. By creating a seamless integration between Pages and Cloudflare Workers, we will be able to host the frontend and backend together, at the edge of the Internet and close to your users. The Linc team is joining Cloudflare to help us do just that.

Today, we're excited to announce the acquisition of Linc, an automation platform to help front-end developers collaborate and build powerful applications. Linc has done amazing work with Frontend Application Bundles (FABs), making dynamic backends more accessible to frontend developers. Their approach offers a straightforward path to building end-to-end applications on Pages, with both frontend logic and powerful backend logic in one bundle. With the addition of Linc, we will accelerate Pages to enable richer and more powerful full-stack applications.

Combining Cloudflare's edge network with Linc's approach to server-side rendering, we're able to set a new standard for performance on the web by delivering the speed of powerful servers close to users. Now, I'll hand it over to Glen Maddern, who was the CTO of Linc, to share why they joined Cloudflare.

Linc and the Frontend Application Bundle (FAB) specification were designed with a single goal in mind: to give frontend developers the best possible tools to build, review, refine, and deploy their applications. An important piece of that is making server-side logic and rendering much more accessible, regardless of what type of app you're building.

Static vs Dynamic frontends

One of the biggest problems in frontend web development today is the dramatic difference in complexity when moving from generating static sites (e.g. building a directory full of HTML, JS, and CSS files) to hosting a full application (traditionally using NodeJS and a web server like Express). While you gain the flexibility of being able to render everything on-demand and customised for the current user, you increase your maintenance cost - you now have servers that you need to keep running. And unless you're operating at a global scale already, you'll often see worse end-user performance as your requests are only being served from one or maybe a couple of locations worldwide.

While serverless platforms have arisen to solve these problems for backend services and can be brought to bear on frontend apps, they're much less cost-effective than using static hosting, especially if the bulk of your frontend assets are static. As such, we've seen a rise of technologies under the umbrella term of 'JAMstack'; they aim at making static sites more powerful (like rebuilding based off CMS updates), or at making it possible to deploy small pieces of server-side APIs as 'cloud functions', along with each update of your app. But it's still fundamentally a limited architecture - you always have a static layer between you and your users, so the more dynamic your needs, the more complex your build pipeline becomes, or the more you're forced to rely on client-side logic.

FABs took a different approach: a deployment artefact that could support the full range of server-side needs, from entirely static sites, apps with some API routes or cloud functions, all the way to full server-side streaming rendering. We also made it compatible with all the cloud hosting providers you might want, so that deploying becomes as easy as uploading a ZIP file. Then, as your needs change, as dynamic content becomes more important, as new frameworks arise that offer increasing performance or you look at moving which provider you're hosting with, you never need to change your tooling and deployment processes.

The FAB approach

Regardless of what framework you're working with, the FAB compiler generates a fab.zip file that has two components: a server.js file that acts as a server-side entry point, and an _assets directory that stores the HTML, CSS, JS, images, and fonts that are sent to the client.

This simple structure gives us enough flexibility to handle all kinds of apps. For example, a static site will have a server.js of only a few auto-generated lines of server-side code, just enough to add redirects for any files outside the _assets directory. On the other end of the spectrum, an app with full server rendering looks and works exactly the same. It just has a lot more code inside its server.js file.

On a server running NodeJS, serving a compiled FAB is as easy as fab serve fab.zip, but FABs are really designed with production class hosting in mind. They make use of world-class CDNs and the best serverless hosting platforms around.

When a FAB is deployed, it's often split into these component parts and deployed separately. Assets are sent to a low-cost object storage platform with a CDN in front of it, and the server component is sent to dedicated serverless hosting. It's all deployed in an atomic, idempotent manner that feels as simple as uploading static files, but completely unlocks dynamic server-side code as part of your architecture.

That generic architecture works great and is compatible with virtually every hosting platform around, but it works slightly differently on Cloudflare Workers.

Workers, unlike other serverless platforms, truly runs at the edge: there is no CDN or load balancer in front of it to split off /_assets routes and send them directly to the Assets storage. This means that every request hits the worker, whether it's triggering a full page render or piping through the bytes for an image file. It might feel like a downside, but with Workers' performance and cost profile, it's quite the opposite - it actually gives us much more flexibility in what we end up building, and gets us closer to the goal of fully unlocking server-side code.

To give just one example, we no longer need to store our asset files on a dedicated static file host - instead, we can use Cloudflare's global key-value storage: Workers KV. Our server.js running inside a Worker can then map /_assets requests directly into the KV store and stream the result to the user. This results in significantly better performance than proxying to a third-party asset host.

What we've found is that Cloudflare offered the most 'FAB-native' hosting option, and so it's very exciting to have the opportunity to further develop what they can do.

Linc + Cloudflare

As we stated above, Linc's goal was to give frontend developers the best tooling to build and refine their apps, regardless of which hosting they were using. But we started to notice an important trend - if a team had a free choice for where to host their frontend, they inevitably chose Cloudflare Workers. In some cases, for a period, teams even used Linc to deploy a FAB to Workers alongside their existing hosting to demonstrate the performance improvement before migrating permanently.

At the same time, we started to see more and more opportunities to fully embrace edge-rendering and make global serverless hosting more powerful and accessible. But the most exciting ideas required deep integration with the hosting providers themselves. Which is why, when we started talking to Cloudflare, everything fell into place.

We're so excited to join the Cloudflare effort and work on expanding Cloudflare Pages to cover the full spectrum of applications. Not only do they share our goal of bringing sophisticated technology to every development team, but with innovations like Durable Objects starting to offer new storage paradigms, the potential for a truly next-generation deployment, review & hosting platform is tantalisingly close.

Disclaimer

CloudFlare Inc. published this content on 22 December 2020 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 22 December 2020 13:14:02 UTC


© Publicnow 2020
All news about CLOUDFLARE, INC.
08:58aCLOUDFLARE  : William O'Neil Starts Cloudflare at Buy
MT
06/17CLOUDFLARE  : Announcing WARP for Linux and Proxy Mode
PU
06/16CLOUDFLARE  : Building Waiting Room on Workers and Durable Objects
PU
06/15CLOUDFLARE  : WAF integration with Azure Active Directory B2C
PU
06/11CLOUDFLARE  : Interconnect Anywhere — Reach Cloudflare's network from 1,60..
PU
06/10CLOUDFLARE  : Introducing Zero Trust Private Networking
PU
06/09CLOUDFLARE  : Celebrating 7 Years of Project Galileo
PU
06/08CLOUDFLARE  : Modify HTTP request headers with Transform Rules
PU
06/07CLOUDFLARE, INC.  : Submission of Matters to a Vote of Security Holders (form 8-..
AQ
06/07Want to Invest in Cybersecurity? Here Are Some ETFs to Consider -- Journal Re..
DJ
More news
Financials (USD)
Sales 2021 615 M - -
Net income 2021 -151 M - -
Net cash 2021 611 M - -
P/E ratio 2021 -200x
Yield 2021 -
Capitalization 31 277 M 31 277 M -
EV / Sales 2021 49,9x
EV / Sales 2022 37,6x
Nbr of Employees 1 931
Free-Float 75,6%
Chart CLOUDFLARE, INC.
Duration : Period :
Cloudflare, Inc. Technical Analysis Chart | MarketScreener
Full-screen chart
Technical analysis trends CLOUDFLARE, INC.
Short TermMid-TermLong Term
TrendsBullishBullishBullish
Income Statement Evolution
Consensus
Sell
Buy
Mean consensus BUY
Number of Analysts 16
Average target price 96,20 $
Last Close Price 100,69 $
Spread / Highest target 9,25%
Spread / Average Target -4,46%
Spread / Lowest Target -23,5%
EPS Revisions
Managers and Directors
NameTitle
Matthew Browning Prince Chairman & Chief Executive Officer
Michelle Marie Zatlyn President, Chief Operating Officer & Director
Thomas Josef Seifert Chief Financial Officer
John Graham-Cumming Chief Technology Officer
Rick Magarro Head-IT Operations Engineer
Sector and Competitors
1st jan.Capitalization (M$)
CLOUDFLARE, INC.32.50%31 277
SALESFORCE.COM, INC.9.84%226 342
DYNATRACE, INC.29.67%15 916
SINCH AB (PUBL)5.84%12 016
NUTANIX, INC.16.76%7 872
ANAPLAN, INC.-25.34%7 763