Real-Time In-Stream Inference with AWS Kinesis, SageMaker & Apache Flink

Post Syndicated from Shawn Sachdev original https://aws.amazon.com/blogs/architecture/realtime-in-stream-inference-kinesis-sagemaker-flink/

As businesses race to digitally transform, the challenge is to cope with the amount of data, and the value of that data diminishes over time. The challenge is to analyze, learn, and infer from real-time data to predict future states, as well as to detect anomalies and get accurate results. In this blog post, we’ll explain the architecture for a solution that can achieve real-time inference on streaming data. We’ll also cover the integration of Amazon Kinesis Data Analytics (KDA) with Apache Flink to asynchronously invoke any underlying services (or databases).

Managed real-time in-stream data inference is quite a mouthful; let’s break it up:

  • In-stream data refers to the capability of processing a data stream that collects, processes, and analyzes data.
  • Real-time inference refers to the ability to use data from the feed to project future state for the underlying data.

Consider a streaming application that captures credit card transactions along with the other parameters (such as source IP to capture the geographic details of the transaction as well as the  amount). This data can then be used to be used to infer fraudulent transactions instantaneously. Compare that to a traditional batch-oriented approach that identifies fraudulent transactions at the end of every business day and generates a report when it’s too late, after bad actors have already committed fraud.

Architecture overview

In this post, we discuss how you can use Amazon Kinesis Data Analytics for Apache Flink (KDA), Amazon SageMaker, Apache Flink, and Amazon API Gateway to address the challenges such as real-time fraud detection on a stream of credit card transaction data. We explore how to build a managed, reliable, scalable, and highly available streaming architecture based on managed services that substantially reduce the operational overhead compared to a self-managed environment. Our particular focus is on how to prepare and run Flink applications with KDA for Apache Flink applications.

The following diagram illustrates this architecture:

Run Apache Flink applications with KDA for Apache Flink applications

In above architecture, data is ingested in AWS Kinesis Data Streams (KDS) using Amazon Kinesis Producer Library (KPL), and you can use any ingestion patterns supported by KDS. KDS then streams the data to an Apache Flink-based KDA application. KDA manages the required infrastructure for Flink, scales the application in response to changing traffic patterns, and automatically recovers from underlying failures. The Flink application is configured to call an API Gateway endpoint using Asynchronous I/O. Residing behind the API Gateway is an AWS SageMaker endpoint, but any endpoints can be used based on your data enrichment needs. Flink distributes the data across one or more stream partitions, and user-defined operators can transform the data stream.

Let’s talk about some of the key pieces of this architecture.

What is Apache Flink?

Apache Flink is an open source distributed processing framework that is tailored to stateful computations over unbounded and bounded datasets. The architecture uses KDA with Apache Flink to run in-stream analytics and uses Asynchronous I/O operator to interact with external systems.

KDA and Apache Flink

KDA for Apache Flink is a fully managed AWS service that enables you to use an Apache Flink application to process streaming data. With KDA for Apache Flink, you can use Java or Scala to process and analyze streaming data. The service enables you to author and run code against streaming sources. KDA provides the underlying infrastructure for your Flink applications. It handles core capabilities like provisioning compute resources, parallel computation, automatic scaling, and application backups (implemented as checkpoints and snapshots).

Flink Asynchronous I/O Operator

Flink Asynchronous I/O Operator

Flink’s Asynchronous I/O operator allows you to use asynchronous request clients for external systems to enrich stream events or perform computation. Asynchronous interaction with the external system means that a single parallel function instance can handle multiple requests and receive the responses concurrently. In most cases this leads to higher streaming throughput. Asynchronous I/O API integrates well with data streams, and handles order, event time, fault tolerance, etc. You can configure this operator to call external sources like databases and APIs. The architecture pattern explained in this post is configured to call API Gateway integrated with SageMaker endpoints.

Please refer code at kda-flink-ml, a sample Flink application with implementation of Asynchronous I/O operator to call an external Sagemaker endpoint via API Gateway. Below is the snippet of code of StreamingJob.java from sample Flink application.

DataStream<HttpResponse<RideRequest>> predictFareResponse =
            // Asynchronously call predictFare Endpoint
            AsyncDataStream.unorderedWait(
                predictFareRequests,
                new Sig4SignedHttpRequestAsyncFunction<>(predictFareEndpoint, apiKeyHeader),
                30, TimeUnit.SECONDS, 20
            )
            .returns(newTypeHint<HttpResponse<RideRequest>() {});

The operator code above requires following inputs:

  1. An input data stream
  2. An implementation of AsyncFunction that dispatches the requests to the external system
  3. Timeout, which defines how long an asynchronous request may take before it considered failed
  4. Capacity, which defines how many asynchronous requests may be in progress at the same time

How Amazon SageMaker fits into this puzzle

In our architecture we are proposing a SageMaker endpoint for inferencing that is invoked via API Gateway, which can detect fraudulent transactions.

Amazon SageMaker is a fully managed service that provides every developer and data scientist with the ability to build, train, and deploy machine learning (ML) models quickly. SageMaker removes the heavy lifting from each step of the machine learning process to make it easier to build and develop high quality models. You can use these trained models in an ingestion pipeline to make real-time inferences.

You can set up persistent endpoints to get predictions from your models that are deployed on SageMaker hosting services. For an overview on deploying a single model or multiple models with SageMaker hosting services, see Deploy a Model on SageMaker Hosting Services.

Ready for a test drive

To help you get started, we would like to introduce an AWS Solution: AWS Streaming Data Solution for Amazon Kinesis (Option 4) that is available as a single-click cloud formation template to assist you in quickly provisioning resources to get your real-time in-stream inference pipeline up and running in a few minutes. In this solution we leverage AWS Lambda, but that can be switched with a SageMaker endpoint to achieve the architecture discussed earlier in this post. You can also leverage the pre-built AWS Solutions Construct, which implements an Amazon API Gateway connected to an Amazon SageMaker endpoint pattern that can replace AWS Lambda in the below solution. See the implementation guide for this solution.

The following diagram illustrates the architecture for the solution:

architecture for the solution

Conclusion

In this post we explained the architecture to build a managed, reliable, scalable, and highly available application that is capable of real-time inferencing on a data stream. The architecture was built using KDS, KDA for Apache Flink, Apache Flink, and Amazon SageMaker. The architecture also illustrates how you can use managed services so that you don’t need to spend time provisioning, configuring, and managing the underlying infrastructure. Instead, you can spend your time creating insights and inference from your data.

We also talked about the AWS Streaming Data Solution for Amazon Kinesis, which is an AWS vetted solution that provides implementations for applications you can automatically deploy directly into your AWS account. The solution automatically configures the AWS services necessary to easily capture, store, process, and infer from streaming data.

Security updates for Friday

Post Syndicated from original https://lwn.net/Articles/838469/rss

Security updates have been issued by Arch Linux (go, libxml2, postgresql, and wireshark-cli), Debian (drupal7 and lxml), Fedora (drupal7, java-1.8.0-openjdk-aarch32, libxml2, pacemaker, slurm, and swtpm), openSUSE (c-ares, ceph, chromium, dash, firefox, go1.14, java-1_8_0-openjdk, kernel, krb5, perl-DBI, podman, postgresql10, postgresql12, rclone, slurm, ucode-intel, wireshark, wpa_supplicant, and xen), SUSE (ceph, firefox, kernel, LibVNCServer, and python), and Ubuntu (freerdp, poppler, and xdg-utils).

ICYMI: Serverless pre:Invent 2020

Post Syndicated from James Beswick original https://aws.amazon.com/blogs/compute/icymi-serverless-preinvent-2020/

During the last few weeks, the AWS serverless team has been releasing a wave of new features in the build-up to AWS re:Invent 2020. This post recaps some of the most important releases for serverless developers.

re:Invent is virtual and free to all attendees in 2020 – register here. See the complete list of serverless sessions planned and join the serverless DA team live on Twitch. Also, follow your DAs on Twitter for live recaps and Q&A during the event.

AWS re:Invent 2020

AWS Lambda

We launched Lambda Extensions in preview, enabling you to more easily integrate monitoring, security, and governance tools into Lambda functions. You can also build your own extensions that run code during Lambda lifecycle events, and there is an example extensions repo for starting development.

You can now send logs from Lambda functions to custom destinations by using Lambda Extensions and the new Lambda Logs API. Previously, you could only forward logs after they were written to Amazon CloudWatch Logs. Now, logging tools can receive log streams directly from the Lambda execution environment. This makes it easier to use your preferred tools for log management and analysis, including Datadog, Lumigo, New Relic, Coralogix, Honeycomb, or Sumo Logic.

Lambda Extensions API

Lambda launched support for Amazon MQ as an event source. Amazon MQ is a managed broker service for Apache ActiveMQ that simplifies deploying and scaling queues. This integration increases the range of messaging services that customers can use to build serverless applications. The event source operates in a similar way to using Amazon SQS or Amazon Kinesis. In all cases, the Lambda service manages an internal poller to invoke the target Lambda function.

We also released a new layer to make it simpler to integrate Amazon CodeGuru Profiler. This service helps identify the most expensive lines of code in a function and provides recommendations to help reduce cost. With this update, you can enable the profiler by adding the new layer and setting environment variables. There are no changes needed to the custom code in the Lambda function.

Lambda announced support for AWS PrivateLink. This allows you to invoke Lambda functions from a VPC without traversing the public internet. It provides private connectivity between your VPCs and AWS services. By using VPC endpoints to access the Lambda API from your VPC, this can replace the need for an Internet Gateway or NAT Gateway.

For developers building machine learning inferencing, media processing, high performance computing (HPC), scientific simulations, and financial modeling in Lambda, you can now use AVX2 support to help reduce duration and lower cost. By using packages compiled for AVX2 or compiling libraries with the appropriate flags, your code can then benefit from using AVX2 instructions to accelerate computation. In the blog post’s example, enabling AVX2 for an image-processing function increased performance by 32-43%.

Lambda now supports batch windows of up to 5 minutes when using SQS as an event source. This is useful for workloads that are not time-sensitive, allowing developers to reduce the number of Lambda invocations from queues. Additionally, the batch size has been increased from 10 to 10,000. This is now the same as the batch size for Kinesis as an event source, helping Lambda-based applications process more data per invocation.

Code signing is now available for Lambda, using AWS Signer. This allows account administrators to ensure that Lambda functions only accept signed code for deployment. Using signing profiles for functions, this provides granular control over code execution within the Lambda service. You can learn more about using this new feature in the developer documentation.

Amazon EventBridge

You can now use event replay to archive and replay events with Amazon EventBridge. After configuring an archive, EventBridge automatically stores all events or filtered events, based upon event pattern matching logic. You can configure a retention policy for archives to delete events automatically after a specified number of days. Event replay can help with testing new features or changes in your code, or hydrating development or test environments.

EventBridge archived events

EventBridge also launched resource policies that simplify managing access to events across multiple AWS accounts. This expands the use of a policy associated with event buses to authorize API calls. Resource policies provide a powerful mechanism for modeling event buses across multiple account and providing fine-grained access control to EventBridge API actions.

EventBridge resource policies

EventBridge announced support for Server-Side Encryption (SSE). Events are encrypted using AES-256 at no additional cost for customers. EventBridge also increased PutEvent quotas to 10,000 transactions per second in US East (N. Virginia), US West (Oregon), and Europe (Ireland). This helps support workloads with high throughput.

AWS Step Functions

Synchronous Express Workflows have been launched for AWS Step Functions, providing a new way to run high-throughput Express Workflows. This feature allows developers to receive workflow responses without needing to poll services or build custom solutions. This is useful for high-volume microservice orchestration and fast compute tasks communicating via HTTPS.

The Step Functions service recently added support for other AWS services in workflows. You can now integrate API Gateway REST and HTTP APIs. This enables you to call API Gateway directly from a state machine as an asynchronous service integration.

Step Functions now also supports Amazon EKS service integration. This allows you to build workflows with steps that synchronously launch tasks in EKS and wait for a response. In October, the service also announced support for Amazon Athena, so workflows can now query data in your S3 data lakes.

These new integrations help minimize custom code and provide built-in error handling, parameter passing, and applying recommended security settings.

AWS SAM CLI

The AWS Serverless Application Model (AWS SAM) is an AWS CloudFormation extension that makes it easier to build, manage, and maintains serverless applications. On November 10, the AWS SAM CLI tool released version 1.9.0 with support for cached and parallel builds.

By using sam build --cached, AWS SAM no longer rebuilds functions and layers that have not changed since the last build. Additionally, you can use sam build --parallel to build functions in parallel, instead of sequentially. Both of these new features can substantially reduce the build time of larger applications defined with AWS SAM.

Amazon SNS

Amazon SNS announced support for First-In-First-Out (FIFO) topics. These are used with SQS FIFO queues for applications that require strict message ordering with exactly once processing and message deduplication. This is designed for workloads that perform tasks like bank transaction logging or inventory management. You can also use message filtering in FIFO topics to publish updates selectively.

SNS FIFO

AWS X-Ray

X-Ray now integrates with Amazon S3 to trace upstream requests. If a Lambda function uses the X-Ray SDK, S3 sends tracing headers to downstream event subscribers. With this, you can use the X-Ray service map to view connections between S3 and other services used to process an application request.

AWS CloudFormation

AWS CloudFormation announced support for nested stacks in change sets. This allows you to preview changes in your application and infrastructure across the entire nested stack hierarchy. You can then review those changes before confirming a deployment. This is available in all Regions supporting CloudFormation at no extra charge.

The new CloudFormation modules feature was released on November 24. This helps you develop building blocks with embedded best practices and common patterns that you can reuse in CloudFormation templates. Modules are available in the CloudFormation registry and can be used in the same way as any native resource.

Amazon DynamoDB

For customers using DynamoDB global tables, you can now use your own encryption keys. While all data in DynamoDB is encrypted by default, this feature enables you to use customer managed keys (CMKs). DynamoDB also announced support for global tables in the Europe (Milan) and Europe (Stockholm) Regions. This feature enables you to scale global applications for local access in workloads running in different Regions and replicate tables for higher availability and disaster recovery (DR).

The DynamoDB service announced the ability to export table data to data lakes in Amazon S3. This enables you to use services like Amazon Athena and AWS Lake Formation to analyze DynamoDB data with no custom code required. This feature does not consume table capacity and does not impact performance and availability. To learn how to use this feature, see this documentation.

AWS Amplify and AWS AppSync

You can now use existing Amazon Cognito user pools and identity pools for Amplify projects, making it easier to build new applications for an existing user base. AWS Amplify Console, which provides a fully managed static web hosting service, is now available in the Europe (Milan), Middle East (Bahrain), and Asia Pacific (Hong Kong) Regions. This service makes it simpler to bring automation to deploying and hosting single-page applications and static sites.

AWS AppSync enabled AWS WAF integration, making it easier to protect GraphQL APIs against common web exploits. You can also implement rate-based rules to help slow down brute force attacks. Using AWS Managed Rules for AWS WAF provides a faster way to configure application protection without creating the rules directly. AWS AppSync also recently expanded service availability to the Asia Pacific (Hong Kong), Middle East (Bahrain), and China (Ningxia) Regions, making the service now available in 21 Regions globally.

Still looking for more?

Join the AWS Serverless Developer Advocates on Twitch throughout re:Invent for live Q&A, session recaps, and more! See this page for the full schedule.

For more serverless learning resources, visit Serverless Land.

ASICs at the Edge

Post Syndicated from Tom Strickx original https://blog.cloudflare.com/asics-at-the-edge/

ASICs at the Edge

At Cloudflare we pride ourselves in our global network that spans more than 200 cities in over 100 countries. To handle all the traffic passing through our network, there are multiple technologies at play. So let’s have a look at one of the cornerstones that makes all of this work… ASICs. No, not the running shoes.

What’s an ASIC?

ASIC stands for Application Specific Integrated Circuit. The name already says it, it’s a chip with a very narrow use case, geared towards a single application. This is in stark contrast to a CPU (Central Processing Unit), or even a GPU (Graphics Processing Unit). A CPU is designed and built for general purpose computation, and does a lot of things reasonably well. A GPU is more geared towards graphics (it’s in the name), but in the last 15 years, there’s been a drastic shift towards GPGPU (General Purpose GPU), in which technologies such as CUDA or OpenCL allow you to use the highly parallel nature of the GPU to do general purpose computing. A good example of GPU use is video encoding, or more recently, computer vision, used in applications such as self-driving cars.

Unlike CPUs or GPUs, ASICs are built with a single function in mind. Great examples are the Google Tensor Processing Units (TPU), used to accelerate machine learning functions[1], or for orbital maneuvering[2], in which specific orbital maneuvers are encoded, like the Hohmann Transfer, used to move rockets (and their payloads) to a new orbit at a different altitude. And they are also heavily used in the networking industry. Technically, the use case in the network industry should be called an ASSP (Application Specific Standard Product), but network engineers are simple people, so we prefer to call it an ASIC.

Why an ASIC

ASICs have the major benefit of being hyper-efficient. The more complex hardware is, the more it will need cooling and power. As ASICs only contain the hardware components needed for their function, their overall size can be reduced, and so are their power requirements. This has a positive impact on the overall physical size of the network (devices don’t need to be as bulky to provide sufficient cooling), and helps reduce the power consumption of a data center.

Reducing hardware complexity also reduces the failure rate of the manufacturing process, and allows for easier production.

The downside is that you need to embed a lot of your features in hardware, and once a new technology or specification comes around, any chips made without that technology baked in, won’t be able to support it (VXLAN for example).

For network equipment, this works perfectly. Overall, the networking industry is slow-moving, and considerable time is taken before new technologies make it to the market (as can be seen with IPv6, MPLS implementations, xDSL availability, …). This means the chips don’t need to evolve on a yearly basis, and can instead be created on a much slower cycle, with bigger leaps in technology. For example, it took Broadcom two years to go from Tomahawk 3 to Tomahawk 4, but in that process they doubled the throughput. The benefits listed earlier are super helpful for network equipment, as they allow for considerable throughput in a small form factor.

Building an ASIC

As with chips of any kind, building an ASIC is a long-term process. Just like with CPUs, if there’s a defect in the hardware design, you have to start from scratch, and scrap the entire build line. As such, the development lifecycle is incredibly long. It starts with prototyping in an FPGA (Field Programmable Gate Array), in which chip designers can program their required functionality and confirm compatibility. All of this is done in a HDL (Hardware Description Language), such as Verilog.

Once the prototyping stage is over, they move to baking the new packet processing pipeline into the chip at a foundry. After that, no more changes can be made to the chip, as it’s literally baked into the hardware (unlike an FPGA, which can be reprogrammed). Further difficulty is added by the fact that there are a very small number of hardware companies that will buy ASICs in bulk to build equipment with; as such the unit cost can increase drastically.

All of this means that the iteration cycle of an ASIC tends to be on the slower side of things (compared to the yearly refreshes in the Intel Process-Architecture-Optimization model for example), and will usually be smaller incremental updates: For example, increases in port-speeds are incremental (1G → 10G → 25G → 40G → 100G → 400G → 800G → …), and are tied into upgrades to the SerDes (Serialiser/Deserialiser) part of the chip.

New protocol support is a lot harder, and might require multiple development cycles before it shows up in a chip.

What ASICs do

The ASICs in our network equipment are responsible for the switching and routing of packets, as well as being the first layer of defense (in the form of a stateless firewall). Due to the sheer nature of how fast packets get switched, fast memory access is a primary concern. Most ASICs will use a special sort of memory, called TCAM (Ternary Content-Addressable Memory). This memory will be used to store all sorts of lookup tables. These may be forwarding tables (where does this packet go), ACL (Access Control List) tables (is this packet allowed), or CoS (Class of Service) tables (which priority should be given to this packet)

CAM, and its more advanced sibling, TCAM, are fascinating kinds of memory, as they operate fundamentally different than traditional Random Access Memory (RAM). While you have to use a memory address to access data in RAM, with CAM and TCAM you can directly refer to the content you are looking for. It is a physical implementation of a key-value store.

In CAM you use the exact binary representation of a word, in a network application, that word is likely going to be an IP address, so 11001011.00000000.01110001.00000000 for example (203.0.113.0). While this is definitely useful, networks operate a big collection of IP addresses, and storing each individually would require significant memory. To remedy this memory requirement, TCAM can store three states, instead of the binary two. This third state, sometimes called ‘ignore’ state, allows for the storage of multiple sequential data words as a single entry.

In networking, these sequential data words are IP prefixes. So for the previous example, if we wanted to store the collection of that IP address, and the 254 IPs following it, in TCAM it would as follows: 11001011.00000000.01110001.XXXXXXXX (203.0.113.0/24). This storage method means we can ask questions of the ASIC such as “where should I send packets with the destination IP address of 203.0.113.19”, to which the ASIC can have a reply ready in a single clock cycle, as it does not need to run through all memory, but instead can directly reference the key. This reply will usually be a reference to a memory address in traditional RAM, where more data can be stored, such as output port, or firewall requirements for the packet.
ASICs at the Edge

To dig a bit deeper into what ASICs do in network equipment, let’s briefly go over some fundamentals.

Networking can be split into two primary components: routing and switching. Switching allows you to directly interconnect multiple devices, so they can talk with each other across the network. It’s what allows your phone to connect to your TV to play a new family video. Routing is the next level up. It’s the mechanism that interconnects all these switched networks into a network of networks, and eventually, the Internet.

So routers are the devices responsible for steering traffic through this complex maze of networks, so it gets to its destination safely, and hopefully, as fast as possible. On the Internet, routers will usually use a routing protocol called BGP (Border Gateway Protocol) to exchange reachability information for a prefix (a collection of IP addresses), also called NLRI (Network Layer Reachability Information).

As with navigating the roads, there are multiple ways to get from point A to point B on the Internet. To make sure the router makes the right decision, it will store all of the reachability information in the RIB (Routing Information Base). That way, if anything changes with one route, the router still has other options immediately available.

With this information, a BGP daemon can calculate the ideal path to take for any given destination from its own point-of-view. This Cisco documentation explains the decision process the daemon goes through to calculate that ideal path.

Once we have this ideal path for a given destination, we should store this information, as it would be very inefficient to calculate this every single time we need to go there. The storage database is called the FIB (Forwarding Information Base). The FIB will be a subset of the RIB, as it will only ever contain the best path for a destination at any given time, while the RIB keeps all the available paths, even the non-ideal ones.

With these individual components, routers can make packets go from point A to point B in a blink of an eye.

Here’ are some of the more specific functions our ASICs need to perform:

  1. FIB install: Once the router has calculated its FIB, it’s important the router can access this as quickly as possible. To do so, the ASIC will install (write) this calculated FIB into the TCAM, so any lookups can happen as quickly as possible.
    ASICs at the Edge

  2. Packet forwarding lookups: as we need to know where to send a received packet, we look up this information in TCAM, which is, as we mentioned, incredibly fast.

  3. Stateless Firewall: while a router routes packets between destinations, you also want to ensure that certain packets don’t reach a destination at all. This can be done using either a stateless or stateful firewall. “State” in this case refers to TCP state, so the router would need to understand if a connection is new, or already established. As maintaining state is a complex issue, which requires storing tables, and can quickly consume a lot of memory, most routers will only operate a stateless firewall.
    Instead, stateful firewalls often have their own appliances. At Cloudflare, we’ve opted to move maintaining state to our compute nodes, as that severely reduces the state-table (one router for all state vs X metals for all state combined). A stateless firewall makes use of the TCAM again to store rules on what to do with specific types of packets. For example, one of the rules we employ at our edge is DENY-BOGON-RANGES , in which we discard traffic sourced from RFC1918 space (and other unroutable space). As this makes use of TCAM, it can all be done at line rate (the maximum speed of the interface).

  4. Advanced features, such as GRE encapsulation: modern networking isn’t just packet switching and packet routing anymore, and more advanced features are needed. One of these is encapsulation. With packet encapsulation, a system will put a data packet into another data packet. Using this technique, it’s possible to build a network on top of an existing network (an overlay). Overlays can be used to build a virtual backbone for example, in which multiple locations can be virtually connected through the Internet.
    While you can encapsulate packets on a CPU (we do this for Magic Transit), there are considerable challenges in doing so in software. As such, the ASIC can have built-in functionality to encapsulate a packet in a multitude of protocols, such as GRE. You may not want encapsulated packets to have to take a second trip through your entire pipeline, as this adds latency, so these shortcuts can also be built into the chip.

  5. MPLS, EVPN, VXLAN, SDWAN, SDN, …: I ran out of buzzwords to enumerate here, but while MPLS isn’t new (the first RFC was created in 2001), it’s a rather advanced requirement, just as the others listed, which means not all ASIC vendors will implement this for all their chips due to the increased complexity.

Vendor Landscape

At Cloudflare, we interact with both hardware and software vendors on a daily basis while operating our global network. As we’re talking about ASICs today, we’ll explore the hardware landscape, but some hardware vendors also have their own NOS (Network Operating System).
There’s a vast selection of hardware out there, all with different features and pricing. It can become incredibly hard to see the wood for the trees, so we’ll focus on 4 important distinguishing factors: Throughput (how many bits can the ASIC push through), buffer size (how many bits can the ASIC store in memory in case of resource contention), programmability (how easy is it for a third party programmer like Cloudflare to interact directly with the ASIC), feature set (how many advanced things outside of routing/switching can the ASIC do).

The landscape is so varied because different companies have different requirements. A company like Cloudflare has different expectations for its network hardware than your typical corner shop. Even within our own network we’ll have different requirements for the different layers that make up our network.

Broadcom

The elephant in the networking room (or is it the jumbo frame in the switch?) is Broadcom. Broadcom is a semiconductor company, with their primary revenue in the wired infrastructure segment (over 50% of revenue[3]). While they’ve been around since 1991, they’ve become an unstoppable force in the last 10 years, in part due to their reliance on Apple (25% of revenue). As a semiconductor manufacturer, their market dominance is primarily achieved by acquiring other companies. A great example is the acquisition of Dune Networks, which has become an excellent revenue generator as the StrataDNX series of ASIC (Arad, QumranMX, Jericho). As such, they have become the biggest ASIC vendor by far, and own 59% of the entire Ethernet Integrated Circuits market[4].

As such, they supply a lot of merchant silicon to Cisco, Juniper, Arista and others. Up until recently, if you wanted to use the Broadcom SDK to accelerate your packet forwarding, you have to sign so many NDAs you might get a hand cramp, which makes programming them a lot trickier. This changed recently when Broadcom open-sourced their SDK. Let’s have a quick look at some of their products.

Tomahawk

The Tomahawk line of ASICs are the bread-and-butter for the enterprise market. They’re cheap and incredibly fast. The first generation of Tomahawk chips did 3.2Tbps linerate, with low-latency switching. The latest generation of this chip (Tomahawk 4) does 25.6Tbps in a 7nm transistor footprint[5]). As you can’t have a cheap, fast, and full feature set for a single package, this means you lose out on features. In this case, you’re missing most of the more advanced networking technologies such as VXLAN, and you have no buffer to speak of.
As an example of a different vendor using this silicon, you can have a look at the Juniper QFX5200 switching platform.

StrataDNX (Arad, QumranMX, Jericho)

These chipsets came through the acquisition of Dune Networks, and are a collection of high-bandwidth, deep buffer (large amount of memory available to store (buffer) packets) chips, allowing them to be deployed in versatile environments, including the Cloudflare edge. The Arista DCS-7280SR that we run in some of our edge locations as edge routers run on the Jericho chipset. Since then, the chips have evolved, and with Jericho2, Broadcom now have a 10Tbps deep buffer chip[6]. With their fabric chip (this links multiple ASICs together), you can build switches with 48x400G ports[7] without much effort.
Cisco built their NCS5500 line of routers using the QumranMX[8].

Trident

This ASIC is an upgrade from the Tomahawk chipset, with a complex and extensive feature set, while maintaining high throughput rates. The latest Trident4 does 12.8Tbps at incredibly low latencies[9], making it an incredibly flexible platform. It unfortunately has no buffer space to speak of, which limits its scope for Cloudflare, as we need the buffer space to be able to switch between the different port speeds we have on our edge routers. The Arista 7050X and 7300X are built on top of this.

Intel

Intel is well known in the network industry for building stable and high-performance 10G NICs (Network Interface Controller). They’re not known for ASICs. They made an initial attempt with their acquisition of Fulcrum[10], which built the FM6000[11] series of ASIC, but nothing of note was really built with them. Intel decided to try again in 2019 with their acquisition of Barefoot. This small manufacturer is responsible for the Barefoot Tofino ASIC, which may well be a fundamental paradigm shift in the network industry.

Barefoot Tofino

The Tofino[12] is built using a PISA (Protocol Independent Switch Architecture), and using P4 (Programming Protocol-Independent Packet Processors)[13], you can program the data-plane (packet forwarding) as you see fit. It’s a drastic move away from the traditional method of networking, in which direct programming of the ASIC isn’t easily possible, and definitely not through a standard programming language. As an added benefit, P4 also allows you to perform a formal verification of your forwarding program, and be sure that it will do what you expect it to. Caveat: OpenFlow tried this, but unfortunately never really got much traction.
ASICs at the Edge[14]

There are multiple variations of the Tofino 1 available, but the top-end ASIC has a 6.5Tbps linerate capacity. As the ASIC is programmable, its featureset is as rich as you’d want it to be. Unfortunately, the chip does not come with a lot of buffer memory, so we can’t deploy these as edge devices (yet). Both Arista (7170 Series[15]) and Cisco (Nexus 34180YC and 3464C series[16]) have built equipment with the Tofino chip inside.

Mellanox

As some of you may know, Mellanox is the vendor that recently got acquired by Nvidia, which also provides our 25G NICs in our compute nodes. Besides NICs, Mellanox has a well-established line of ASICs, mostly for switching.

Spectrum

The latest iteration of this ASIC, Spectrum 3 offers 12.8Tbps switching capacity, with an extensive featureset, including Deep Packet Inspection and NAT. This chip allows for building dense high-speed port devices, going up to 25.6Tbps[17]. Buffering wise, there’s none to really speak of (64MB). Mellanox also builds their own hardware platforms. Unlike the other vendors below, they aren’t shipped with the Mellanox Operating System, instead, they offer you a variety of choices to run on top, including Cumulus Linux (which was also acquired by Nvidia 🤔).

As mentioned, while we use their NIC technology extensively, we currently don’t have any Mellanox ASIC silicon in our network.

Juniper

Juniper is a network hardware supplier, and currently the biggest supplier of network equipment for Cloudflare. As previously mentioned in the Broadcom section, Juniper buys some of their silicon from Broadcom, but they also have a significant lineup of home-grown silicon, which can be split into 2 families: Trio and Express.

Express

The Express family is the switching-skewed family, where bandwidth is a priority, while still maintaining a broad range of feature capabilities. These chips live in the same application landscape as the Broadcom StrataDNX chips.

Paradise (Q5)

The Q5 is the new generation of the Juniper switching ASIC[18]. While by itself it doesn’t boast high linerates (500Gbps), when combined into a chassis with a fabric chip (Clos network in this case), they can produce switches (or line cards) with up to 12Tbps of throughput capacity[19]. In addition to allowing for high-throughput, dense network appliances, the chip also comes with a staggering amount of buffer space (4GB per ASIC), provided by external HMC (Hybrid Memory Cube). In this HMC, they’ve also decided to put the FIB, MAC and other tables (so no TCAM).
The Q5 chip is used in their QFX1000 lineup of switches, which include the QFX10002-36Q, QFX10002-60C, QFX10002-72Q and QFX10008, all of which are deployed in our datacenters, as either edge routers or core aggregation switches.

ExpressPlus (ZX)

The ExpressPlus is the more feature-rich and faster evolution of the Paradise chip. It offers double the bandwidth per chip (1Tbps) and is built into a combined Clos-fabric reaching 6Tbps in a 2U form-factor (PTX10002). It also has an increased logical scale, which comes with bigger buffers, larger FIB storage, and more ACL space.

The ExpressPlus drives some of the PTX line of IP routers, together with its newest sibling, Triton.

Triton (BT)

Triton is the latest generation of ASIC in the Express family, with 3.6Tbps of capacity per chip, making way for some truly bandwidth-dense hardware. Both Triton and ExpressPlus are 400GE capable.

Trio

The Trio family of chips are primarily used in the feature-heavy MX routing platform, and is currently at its 5th generation.

ASICs at the EdgeA Juniper MPC4E-3D-32XGE line card

Trio Eagle (Trio 4.0) (EA)

The Trio Eagle is the previous generation of the Trio Penta, and can be found on the MPC7E line cards for example. It’s a feature-rich ASIC, with a 400Gbps forwarding capacity, and significant buffer and TCAM capacity (as is to be expected from a routing platform ASIC)

Trio Penta (Trio 5.0) (ZT)

Penta is the new generation routing chip, which is built for the MX platform routers. On top of being a very beefy chip, capable of 500Gbps per ASIC, allowing Juniper to build line cards of up to 4Tbps of capacity, the chip also has a lot of baked in features, offering advanced hardware offloading for for example MACSec, or Layer 3 IPsec.

The Penta chip is packaged on the MPC10E and MPC11E line card, which can be installed in multiple variations of the MX chassis routers (MX480 included).

Cisco

Last but not least, there’s Cisco. As the saying goes “nobody ever got fired for buying Cisco”, they’re the biggest vendor of network solutions around. Just like Juniper, they have a mixed product fleet of merchant silicon, as well as home-grown. While we used to operate Cisco routers as edge routers (Cisco ASR 9000), this is no longer the case. We do still use them heavily for our ToR (Top-of-Rack) switching needs, utilizing both their Nexus 5000 series and Nexus 9000 series switches.

Bigsur

Bigsur is custom silicon developed for the Nexus 6000 line of switches (confusingly, the switches themselves are called Cisco Nexus 5672UP and Cisco Nexus 6001). In our specific model, the Cisco Nexus 5672UP, there’s 7 of them interconnected, providing 10G and 40G connectivity. Unfortunately Cisco is a lot more tight-lipped about their ASIC capabilities, so I can’t go as deep as I did with the Juniper chips. Feature-wise, there’s not a lot we require from them in our edge network. They’re simple Layer 2 forwarding switches, with no added requirements. Buffer wise, they use a system called Virtual Output Queueing, just like the Juniper Express chip. Unlike the Juniper silicon, the Bigsur ASIC doesn’t come with a lot of TCAM or buffer space.

Tahoe

The Tahoe is the Cisco ASIC found in the Cisco 9300-EX switches, also known as the LSE (Leaf Spine Engine). It offers higher-density port configurations compared to the Bigsur (1.6Tbps)[20]. Overall, this ASIC is a maturation of the Bigsur silicon, offering more advanced features such as advanced VXLAN+EVPN fabrics, greater port flexibility (10G, 25G, 40G and 100G), and increased buffer sizes (40MB). We use this ASIC extensively in both our edge data centers as well as in our core data centers.

Conclusion

A lot of different factors come into play when making the decision to purchase the next generation of Cloudflare network equipment. This post only scratches the surface of technical considerations to be made, and doesn’t come near any other factors, such as ecosystem contributions, openness, interoperability, or pricing. None of this would’ve been possible without the contributions from other network engineers—this post was written on the shoulders of giants. In particular, thanks to the excellent work by Jim Warner at UCSC, the engrossing book on the new MX platforms, written by David Roy (Day One: Inside the MX 5G), as well as the best book on the Juniper QFX lineup: Juniper QFX10000 Series by Douglas Richard Hanks Jr, and to finish it off, the Summary of Network ASICs post by Justin Pietsch.


  1. https://cloud.google.com/tpu/ ↩︎

  2. https://angel.co/company/spacex/jobs/744408-sr-fpga-asic-design-engineer ↩︎

  3. https://marketrealist.com/2017/02/wired-infrastructure-segment-protects-broadcom/ ↩︎

  4. https://www.wsj.com/articles/broadcom-lands-deals-to-place-components-in-apple-smartphones-11579821914 ↩︎

  5. https://www.globenewswire.com/news-release/2019/12/09/1958047/0/en/Broadcom-Ships-Tomahawk-4-Industry-s-Highest-Bandwidth-Ethernet-Switch-Chip-at-25-6-Terabits-per-Second.html ↩︎

  6. https://www.broadcom.com/products/ethernet-connectivity/switching/stratadnx/BCM88690 ↩︎

  7. https://www.ufispace.com/products/telco/core-edge/s9705-48d ↩︎

  8. https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKSPG-2900.pdf ↩︎

  9. https://www.broadcom.com/products/ethernet-connectivity/switching/strataxgs/bcm56880-series ↩︎

  10. https://newsroom.intel.com/news-releases/intel-to-acquire-fulcrum-microsystems/ ↩︎

  11. https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-switch-fm5000-fm6000-datasheet.pdf ↩︎

  12. https://barefootnetworks.com/products/brief-tofino/ ↩︎

  13. http://www.sigcomm.org/node/3503 ↩︎

  14. https://github.com/p4lang/p4lang.github.io/blob/master/assets/p4_switch_model-600px.png ↩︎

  15. https://www.arista.com/assets/data/pdf/Whitepapers/7170_White_Paper.pdf ↩︎

  16. https://www.barefootnetworks.com/press-releases/barefoot-networks-to-showcase-technologies-to-build-fast-and-resilient-networks-using-deep-insight-and-tofino-powered-cisco-nexus-switches-at-cisco-live-us-2019/ ↩︎

  17. https://www.mellanox.com/products/ethernet-switches/sn4000 ↩︎

  18. https://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000599-en.pdf ↩︎

  19. https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000531-en.pdf#page=7 ↩︎

  20. https://www.cisco.com/c/dam/global/fr_ch/solutions/data-center-virtualization/pdf/Cisco_Nexus_9300_EX_Platform.pdf#page=8 ↩︎

Undermining Democracy

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/11/undermining-democracy.html

Last Thursday, Rudy Giuliani, a Trump campaign lawyer, alleged a widespread voting conspiracy involving Venezuela, Cuba, and China. Another lawyer, Sidney Powell, argued that Mr. Trump won in a landslide, the entire election in swing states should be overturned and the legislatures should make sure that the electors are selected for the president.

The Republican National Committee swung in to support her false claim that Mr. Trump won in a landslide, while Michigan election officials have tried to stop the certification of the vote.

It is wildly unlikely that their efforts can block Joe Biden from becoming president. But they may still do lasting damage to American democracy for a shocking reason: the moves have come from trusted insiders.

American democracy’s vulnerability to disinformation has been very much in the news since the Russian disinformation campaign in 2016. The fear is that outsiders, whether they be foreign or domestic actors, will undermine our system by swaying popular opinion and election results.

This is half right. American democracy is an information system, in which the information isn’t bits and bytes but citizens’ beliefs. When peoples’ faith in the democratic system is undermined, democracy stops working. But as information security specialists know, outsider attacks are hard. Russian trolls, who don’t really understand how American politics works, have actually had a difficult time subverting it.

When you really need to worry is when insiders go bad. And that is precisely what is happening in the wake of the 2020 presidential election. In traditional information systems, the insiders are the people who have both detailed knowledge and high level access, allowing them to bypass security measures and more effectively subvert systems. In democracy, the insiders aren’t just the officials who manage voting but also the politicians who shape what people believe about politics. For four years, Donald Trump has been trying to dismantle our shared beliefs about democracy. And now, his fellow Republicans are helping him.

Democracy works when we all expect that votes will be fairly counted, and defeated candidates leave office. As the democratic theorist Adam Przeworski puts it, democracy is “a system in which parties lose elections.” These beliefs can break down when political insiders make bogus claims about general fraud, trying to cling to power when the election has gone against them.

It’s obvious how these kinds of claims damage Republican voters’ commitment to democracy. They will think that elections are rigged by the other side and will not accept the judgment of voters when it goes against their preferred candidate. Their belief that the Biden administration is illegitimate will justify all sorts of measures to prevent it from functioning.

It’s less obvious that these strategies affect Democratic voters’ faith in democracy, too. Democrats are paying attention to Republicans’ efforts to stop the votes of Democratic voters ­- and especially Black Democratic voters -­ from being counted. They, too, are likely to have less trust in elections going forward, and with good reason. They will expect that Republicans will try to rig the system against them. Mr. Trump is having a hard time winning unfairly, because he has lost in several states. But what if Mr. Biden’s margin of victory depended only on one state? What if something like that happens in the next election?

The real fear is that this will lead to a spiral of distrust and destruction. Republicans ­ who are increasingly committed to the notion that the Democrats are committing pervasive fraud -­ will do everything that they can to win power and to cling to power when they can get it. Democrats ­- seeing what Republicans are doing ­ will try to entrench themselves in turn. They suspect that if the Republicans really win power, they will not ever give it back. The claims of Republicans like Senator Mike Lee of Utah that America is not really a democracy might become a self-fulfilling prophecy.

More likely, this spiral will not directly lead to the death of American democracy. The U.S. federal system of government is complex and hard for any one actor or coalition to dominate completely. But it may turn American democracy into an unworkable confrontation between two hostile camps, each unwilling to make any concession to its adversary.

We know how to make voting itself more open and more secure; the literature is filled with vital and important suggestions. The more difficult problem is this. How do you shift the collective belief among Republicans that elections are rigged?

Political science suggests that partisans are more likely to be persuaded by fellow partisans, like Brad Raffensperger, the Republican secretary of state in Georgia, who said that election fraud wasn’t a big problem. But this would only be effective if other well-known Republicans supported him.

Public outrage, alternatively, can sometimes force officials to back down, as when people crowded in to denounce the Michigan Republican election officials who were trying to deny certification of their votes.

The fundamental problem, however, is Republican insiders who have convinced themselves that to keep and hold power, they need to trash the shared beliefs that hold American democracy together.

They may have long-term worries about the consequences, but they’re unlikely to do anything about those worries in the near-term unless voters, wealthy donors or others whom they depend on make them pay short-term costs.

This essay was written with Henry Farrell, and previously appeared in the New York Times.

A Byzantine failure in the real world

Post Syndicated from Tom Lianza original https://blog.cloudflare.com/a-byzantine-failure-in-the-real-world/

A Byzantine failure in the real world

An analysis of the Cloudflare API availability incident on 2020-11-02

When we review design documents at Cloudflare, we are always on the lookout for Single Points of Failure (SPOFs). Eliminating these is a necessary step in architecting a system you can be confident in. Ironically, when you’re designing a system with built-in redundancy, you spend most of your time thinking about how well it functions when that redundancy is lost.

On November 2, 2020, Cloudflare had an incident that impacted the availability of the API and dashboard for six hours and 33 minutes. During this incident, the success rate for queries to our API periodically dipped as low as 75%, and the dashboard experience was as much as 80 times slower than normal. While Cloudflare’s edge is massively distributed across the world (and kept working without a hitch), Cloudflare’s control plane (API & dashboard) is made up of a large number of microservices that are redundant across two regions. For most services, the databases backing those microservices are only writable in one region at a time.

Each of Cloudflare’s control plane data centers has multiple racks of servers. Each of those racks has two switches that operate as a pair—both are normally active, but either can handle the load if the other fails. Cloudflare survives rack-level failures by spreading the most critical services across racks. Every piece of hardware has two or more power supplies with different power feeds. Every server that stores critical data uses RAID 10 redundant disks or storage systems that replicate data across at least three machines in different racks, or both. Redundancy at each layer is something we review and require. So—how could things go wrong?

In this post we present a timeline of what happened, and how a difficult failure mode known as a Byzantine fault played a role in a cascading series of events.

2020-11-02 14:43 UTC: Partial Switch Failure

At 14:43, a network switch started misbehaving. Alerts began firing about the switch being unreachable to pings. The device was in a partially operating state: network control plane protocols such as LACP and BGP remained operational, while others, such as vPC, were not. The vPC link is used to synchronize ports across multiple switches, so that they appear as one large, aggregated switch to servers connected to them. At the same time, the data plane (or forwarding plane) was not processing and forwarding all the packets received from connected devices.

This failure scenario is completely invisible to the connected nodes, as each server only sees an issue for some of its traffic due to the load-balancing nature of LACP. Had the switch failed fully, all traffic would have failed over to the peer switch, as the connected links would’ve simply gone down, and the ports would’ve dropped out of the forwarding LACP bundles.

Six minutes later, the switch recovered without human intervention. But this odd failure mode led to further problems that lasted long after the switch had returned to normal operation.

2020-11-02 14:44 UTC: etcd Errors begin

The rack with the misbehaving switch included one server in our etcd cluster. We use etcd heavily in our core data centers whenever we need strongly consistent data storage that’s reliable across multiple nodes.

In the event that the cluster leader fails, etcd uses the RAFT protocol to maintain consistency and establish consensus to promote a new leader. In the RAFT protocol, cluster members are assumed to be either available or unavailable, and to provide accurate information or none at all. This works fine when a machine crashes, but is not always able to handle situations where different members of the cluster have conflicting information.

In this particular situation:

  • Network traffic between node 1 (in the affected rack) and node 3 (the leader) was being sent through the switch in the degraded state,
  • Network traffic between node 1 and node 2 were going through its working peer, and
  • Network traffic between node 2 and node 3 was unaffected.

This caused cluster members to have conflicting views of reality, known in distributed systems theory as a Byzantine fault. As a consequence of this conflicting information, node 1 repeatedly initiated leader elections, voting for itself, while node 2 repeatedly voted for node 3, which it could still connect to. This resulted in ties that did not promote a leader node 1 could reach. RAFT leader elections are disruptive, blocking all writes until they’re resolved, so this made the cluster read-only until the faulty switch recovered and node 1 could once again reach node 3.

A Byzantine failure in the real world

2020-11-02 14:45 UTC: Database system promotes a new primary database

Cloudflare’s control plane services use relational databases hosted across multiple clusters within a data center. Each cluster is configured for high availability. The cluster setup includes a primary database, a synchronous replica, and one or more asynchronous replicas. This setup allows redundancy within a data center. For cross-datacenter redundancy, a similar high availability secondary cluster is set up and replicated in a geographically dispersed data center for disaster recovery. The cluster management system leverages etcd for cluster member discovery and coordination.

When etcd became read-only, two clusters were unable to communicate that they had a healthy primary database. This triggered the automatic promotion of a synchronous database replica to become the new primary. This process happened automatically and without error or data loss.

There was a defect in our cluster management system that requires a rebuild of all database replicas when a new primary database is promoted. So, although the new primary database was available instantly, the replicas would take considerable time to become available, depending on the size of the database. For one of the clusters, service was restored quickly. Synchronous and asynchronous database replicas were rebuilt and started replicating successfully from primary, and the impact was minimal.

For the other cluster, however, performant operation of that database required a replica to be online. Because this database handles authentication for API calls and dashboard activities, it takes a lot of reads, and one replica was heavily utilized to spare the primary the load. When this failover happened and no replicas were available, the primary was overloaded, as it had to take all of the load. This is when the main impact started.

Reduce Load, Leverage Redundancy

At this point we saw that our primary authentication database was overwhelmed and began shedding load from it. We dialed back the rate at which we push SSL certificates to the edge, send emails, and other features, to give it space to handle the additional load. Unfortunately, because of its size, we knew it would take several hours for a replica to be fully rebuilt.

A silver lining here is that every database cluster in our primary data center also has online replicas in our secondary data center. Those replicas are not part of the local failover process, and were online and available throughout the incident. The process of steering read-queries to those replicas was not yet automated, so we manually diverted API traffic that could leverage those read replicas to the secondary data center. This substantially improved our API availability.

The Dashboard

The Cloudflare dashboard, like most web applications, has the notion of a user session. When user sessions are created (each time a user logs in) we perform some database operations and keep data in a Redis cluster for the duration of that user’s session. Unlike our API calls, our user sessions cannot currently be moved across the ocean without disruption. As we took actions to improve the availability of our API calls, we were unfortunately making the user experience on the dashboard worse.

This is an area of the system that is currently designed to be able to fail over across data centers in the event of a disaster, but has not yet been designed to work in both data centers at the same time. After a first period in which users on the dashboard became increasingly frustrated, we failed the authentication calls fully back to our primary data center, and kept working on our primary database to ensure we could provide the best service levels possible in that degraded state.

2020-11-02 21:20 UTC Database Replica Rebuilt

The instant the first database replica rebuilt, it put itself back into service, and performance resumed to normal levels. We re-ramped all of the services that had been turned down, so all asynchronous processing could catch up, and after a period of monitoring marked the end of the incident.

Redundant Points of Failure

The cascade of failures in this incident was interesting because each system, on its face, had redundancy. Moreover, no system fully failed—each entered a degraded state. That combination meant the chain of events that transpired was considerably harder to model and anticipate. It was frustrating yet reassuring that some of the possible failure modes were already being addressed.

A team was already working on fixing the limitation that requires a database replica rebuild upon promotion. Our user sessions system was inflexible in scenarios where we’d like to steer traffic around, and redesigning that was already in progress.

This incident also led us to revisit the configuration parameters we put in place for things that auto-remediate. In previous years, promoting a database replica to primary took far longer than we liked, so getting that process automated and able to trigger on a minute’s notice was a point of pride. At the same time, for at least one of our databases, the cure may be worse than the disease, and in fact we may not want to invoke the promotion process so quickly. Immediately after this incident we adjusted that configuration accordingly.

Byzantine Fault Tolerance (BFT) is a hot research topic. Solutions have been known since 1982, but have had to choose between a variety of engineering tradeoffs, including security, performance, and algorithmic simplicity. Most general-purpose cluster management systems choose to forgo BFT entirely and use protocols based on PAXOS, or simplifications of PAXOS such as RAFT, that perform better and are easier to understand than BFT consensus protocols. In many cases, a simple protocol that is known to be vulnerable to a rare failure mode is safer than a complex protocol that is difficult to implement correctly or debug.

The first uses of BFT consensus were in safety-critical systems such as aircraft and spacecraft controls. These systems typically have hard real time latency constraints that require tightly coupling consensus with application logic in ways that make these implementations unsuitable for general-purpose services like etcd. Contemporary research on BFT consensus is mostly focused on applications that cross trust boundaries, which need to protect against malicious cluster members as well as malfunctioning cluster members. These designs are more suitable for implementing general-purpose services such as etcd, and we look forward to collaborating with researchers and the open source community to make them suitable for production cluster management.

We are very sorry for the difficulty the outage caused, and are continuing to improve as our systems grow. We’ve since fixed the bug in our cluster management system, and are continuing to tune each of the systems involved in this incident to be more resilient to failures of their dependencies.  If you’re interested in helping solve these problems at scale, please visit cloudflare.com/careers.

New book: The Official Raspberry Pi Handbook 2021

Post Syndicated from Ashley Whittaker original https://www.raspberrypi.org/blog/new-book-the-official-raspberry-pi-handbook-2021/

Hey everyone, come and see, come and see! Here’s a great new bookazine from the makers of the official Raspberry Pi magazine. We do love the folks at The MagPi. Clever, they are.

If, like us, you’re over 2020 already, dive into the pages of The Official Raspberry Pi Handbook 2021, and pretend it never happened. That will totally work.

The front cover of the Raspberry Pi Handbook featuring a Raspberry Pi 4 on a dark background

To help you get the most of out of your Raspberry Pi computer, this official Handbook features 200 pages of essential information, inspiring projects, practical tutorials, and definitive reviews.

Beginner-friendly

A blue double page spread on Starter Electronics

If you’re an absolute beginner, you can learn from the Handbook how to set up your Raspberry Pi and start using it. Then you can move on to the step-by-step tutorials that will teach you how to code and make with your Raspberry Pi.

Shiny new stuff

A double page spread about Raspberry Pi 400

You’ll also (re)discover the new Raspberry Pi 400 and High Quality Camera, both released this year. And you’ll find out about the top kits and accessories for your projects.

Be inspired

A double page spread about Reachy robot. Robot is white with big black eyes and a stripy torso

And finally, we’ve also picked out some incredible Raspberry Pi projects made by people in the community to inspire you to get making and coding.

Where can I get the Handbook?

A double page spread on problem solving with Raspberry Pi

You can buy The Official Raspberry Pi Handbook 2021 now from the Raspberry Pi Press online store, or at the Raspberry Pi store in Cambridge, UK.

Personally, we prefer new book smell and the crackle of physical pages but, if you’re less picky and don’t mind on-screen reading, the lovely folks at The MagPi have a PDF version you can download for free.

The post New book: The Official Raspberry Pi Handbook 2021 appeared first on Raspberry Pi.

Проект Медиа: Тайната връзка на руския президент и внезапните богатства на любимата му

Post Syndicated from Екип на Биволъ original https://bivol.bg/putin-krivonogih-proekt-media.html

петък 27 ноември 2020


В Санкт Петербург живее тайнствената мултимилионерка Светлана Кривоногих. Тя получава шикарни подаръци от приятелите на Владимир Путин, а дъщеря й изключително много прилича на държавния глава. Тази история разкрива на кого реално принадлежи банката “Россия”.

Каменният остров е не особено популярна за туристите точка на картата на Санкт Петербург. Но местните знаят, че няма да по-елитно място за живот в града. Наоколо е вода, поддържан парк, не много дореволюционни къщи, познати от съветските филми за Шерлок Холмс, и държавни резиденции със загадъчните названия от типа “К-2”.

Комплексът на Брезовата алея е сред най-елитните в Петербург. Сн. Проект Медиа

В началото на 2000-е години двадесетина петербургци са изпълнили мечтата на много граждани, като се заселват на каменния остров. Това са хора не от числото на обикновените жители на втората столица, това са основно хора от близкия кръг на ранния президент Владимир Путин. Те стават собственици на апартаменти в жилищния комплекс на Брезова алея-2. Комплексът, построен в стила на петербургските къщи от 19 век, е затворен както физически – с ограда и ров с вода, така и символично: да отидеш просто така в офиса на строителя и да се сдобиеш с апартамент е било невъзможно. Тези апартаменти са се предлагали само сред познати.
Впоследствие на Брезова алея се заселват спаринг-партньорите на Путин по джудо Василий Шестаков и Аркадий Ротенберг, приятелите на президента по вилния кооператив “Озеро” Юрий Ковалчук, Сергей Фурсенко, Виктор Мячин и Николай Шамалов, и още редица хора, свързани с руския управник по един или друг начин.

Вероятно най-незабележимият участник в това приятелство се оказва жена, името и фамилията на която нищо не говорят на широката публика. Дори двама от съседите й на Каменния остров махват с ръка в отговор на въпроса на “Проект”: чували сме фамилията й, но никога не сме я виждали и не искаме да знаем.

Непознатата се казва Светлана Кривоногих.

Снимка от профила на Светлана Кривоногих в WhatsApp

Сегашната обитателка на Каменния остров в детството си е живяла в комуналка (квартира, в която живее повече от едно семейство) на ул. “Гороховая”. А наоколо – типичният “бандитски Петербург”. Съседът по стълбищна площадка и брат на една от приятелките й е бил свързан с криминалната престъпност, а в съседния двор е щаб-квартирата на охранителната компания “Балтик Ескорт”. Тя е създадена в трескавите 90-е години от героя на предишния ни материал Роман Цепов, тясно свързан с петербургския криминален свят. Едва ли Цепов е идвал в тази комуналка, но както ще покаже по-нататък разказът, той не би могъл да не знае коя е Светлана Кривоногих.

Както обикновено в комуналката бившето величие на дореволюционната фасада е съпътствано от мизерния бит на обитателите. Старинната, но износена врата на квартирата, в която е живяла Кривоногих, и досега е украсена с пет стари звънеца – според броя на семействата, които някога са си поделяли кухнята, тоалетната и банята. Родителите на Кривоногих са пристигнали в Ленинград от провинцията – майката от Ярославска област, бащата от Саратовска. До раждането на дъщеря им през 1975 г. те са живели в друг район, но после получават разрешение да се заселят на “Гороховая” или, както тогава се е казвала улицата “Дзержински”. Майката е работела като бояджийка в бригада за ремонти на жилища. За бащата на Светлана един съсед помни само, че е бил пияница и доволно рано е умрял.

“Тя беше много обикновена”, спомня си за Кривоногих приятелка от детството. Пари в семейството не е имало. В началото на 90-е Светлана е зрелостничка и започва работа като чистачка в магазин наблизо. После записва международни икономически отношения в университета по икономика и финанси. Но при молба да разкажат за нея, състудентите й само вдигат рамене. “Не помня тя да е идвала на лекции, не я помня и при връчването на дипломите”, казва един от тях.

Университетската си диплома Кривоногих получава през 2000 г., но явно в този период нещо фундаментално се е променило в живота й. Заедно с майка си тя напуска комуналката на “Гороховая” и става собственичка на най-елитното жилище, за каквото петербуржец може само да мечтае, а сега по данни на “Проект” семейството на Кривоногих притежава жилищни имоти в Петербург, Москва и Сочи на стойност почти 1, 1 млрд. рубли. В отговор на въпрос за източниците на неочакваното богатство на Кривоногих двама съседи от “Гороховая” си спомнят, че през 90-те при Светлана се появява заможен мъж. Един от тях казва, че той е бил “чиновник от управата на Петербург”, а другият обидно го нарича “татенце”.

Россиянката

В публичните документи отговор на въпроса за мъжа до Светлана Кривоногих, естествено, няма. Но в тях могат да се намерят източниците на внезапно стоварилото се върху нея богатство. В началото на 2000-е г. довчерашната студентка влиза в капитала на няколко компании, сред които изпъква бързо развиващата се петербургска банка “Россия”.

Тя започва работа в самата банка поне през 2001 г., а после става и акционер в нея. През 2001 г. Кривоногих регистрира в Петербург фирма с игривото название “Релакс”, на която впоследствие се записва делът й в банката. Кога точно “Релакс” се сдобива с част от “Россия”, не става ясно от публичните документи – за пръв път информация за такъв акционер с дял от 3, 6% се появява в банковите документи през 2007 г. Но в началото на 2019 г. Кривоногих е притежавала доста по-малко – около 2, 8%, или близо 800 млн. рубли, според пазарната стойност на банката.

“Россия” е банка, литнала при президента Путин и благодарение на него. Създадена от ленинградски партийни функционери в края на перестройката, до 2000-а г. тя работи предимно в Северо-Запада и открива офис в столицата едва след избора на Путин за президент. След това банката започва да прелива от активи, доставяни от държавната компания “Газпром”.

В началото е фактическата приватизация на застрахователната група “Согаз”, която владее газовия монопол. След президентските избори през 2004 г. За “Согаз” е прието окончателно решение – да се потвърди продажбата на групата на стратегически инвеститор. Путин казва “Банка “Россия” и това е”, спомня си бившият зам.-министър на енергетиката Владимир Милов в интервю за Forbes. Вече 2, 5 г. след покупката “Согаз” донася на акционерите в “Россия” 7, 5 млрд. чиста печалба. “Согаз” е последвана от компанията “Лидер”, чрез която “Россия” става съсобственик на още два от активите на “Газпром” – Газпромбанк и пенсионния фонд “Газфонд”.

Ексклузивният достъп до държавните активи де факто гарантира този ръст, благодарение на който “Россия” влиза в 20-те най-големи банки в страната. През 2014 г., веднага след присъединяването на Крим, банката попада под санкции заради близостта си с Путин. Но президентът мигом я подкрепя с обещанието, че ще си открие сметка в нея и там ще съхранява заплатата си. “Още повече, че според мен, банката има такова звучно и символично име. Тя така и се казва – Русия”, каза той тогава.

“Россия” не случайно излетя в путинска Русия – сред акционерите й няма случайни хора, почти всички са свързани с президента. Основният собственик на банката, според документите, е съседът на Путин в “Озеро” Юрий Ковалчук, който притежава близо 40% от акциите. Но историята на Светлана Кривоногих ще покаже кой е истинският притежател на “Россия”.

Стопанката на планината

В края на януари 2011 г. в планинския ски-курорт “Игора” в северната част на Ленинградска област временно е закрито едно от трасетата. Сред пързалящите се бързо се разнася слухът, че Путин е в планината. Към онзи момент той е министър-председател и като истински вожд по време на спусканията е придружаван от трима охранители, един от които едва не се е претрепал от престараване. Путин наистина обича “Игора”, разположен на 40 км от вилния кооператив “Озеро” – той е пристигнал за откриването на комплекса в началото на 2006 г., там през 2013 г. е отпразнувана сватбата на дъщеря му Катерина и сина на приятеля му Кирил Шамалов.

Този любим на президента курорт принадлежи на същата тази Светлана Кривоногих. Сега тя държи 75% в компанията “Озон”, която управлява “Игора”, владее земята и търговската марка. Юрий Ковалчук и съпругата му притежават едва 25%, макар, че именно собствената му банка бе ключов инвеститор в курорта, печалбата на който през 2019 г. надхвърли половин милиард рубли.

С подкрепата на “Россия” Кривоногих става собственик на още един обект – “Ленинград центр” в Таврическия парк в Петербург. През съветското време “Ленинград” бе кино-театър с панорамен екран, но в началото на 2000-е г. е закрит. По-късно сградата е купена от Ковалчук и започва дълга реконструкция – в началото там намерението е било да се изгради спортен център с трасе за картинг, после кабаре по френски маниер, но впоследствие към 2014 г. се получава културно пространство, в което вървят изложби, спектакли и където награждават местните журналисти със “Златно перо”.

Към онзи момент основен собственик на “Ленинград центр” става Кривоногих с дял от 75%. Четвъртинка, както и в случая с “Игора”, остава за Ковалчук. Впрочем, от идеята за кабарето до края не са се отказали – например, през ноември 2020 г. Там е представен спектакълът “Love Sick”, позициониран като “най-предизвикателното и откровено шоу”.

В залата има маси, сервитьори разнасят безплатно шампанско, цената на билета започва от 25 000 рубли. На сцената – еротично шоу с елементи на акробатика, танци на полугол сатир и девойки в пеньоари на кревата. “Всяка част е като оголен нерв, изградена на контрасти, където имат място сексът и рокендролът”, се посочва в описанието на шоуто. Годишната печалба от секса, рокендрола и изложбите на съвременно изкуство възлиза на малко над 100 млн. рубли.

По принцип, ако вестниците пишат за тези активи, те споменават Кривоногих без акцент, само като лице, приближено до Юрий Ковалчук. Но “Проект” разкри, че Светлана би могла да бъде далеч по-близка до президента, отколкото дори самият Ковалчук.

Приятелката

Вечерта на 4 януари 1999 г. от Пулково към Москва излита поредният самолет. На местата 5а и 5б седят тогавашният директор на ФСБ Владимир Путин и неговият познат служебно от Смолни Виктор Золотов. Пред тях на 1б се е разположила Светлана Кривоногих. Съвпадение или не, но тя е купила билета си 7-8 минути преди Золотов и Путин.

Кривоногих изобщо често е можело да бъде видяна по самолетите, летящи между Петербург и Москва. Нейна постоянна спътничка е девойка с името Дина Цилевич. Не става дума за случайни съвпадения – те явно са си били приятелки, купували си билетите заедно и са сядали една до друга. Най-малко два пъти ги е придружавал Золотов.

Снимка от профила на Светлана Кривоногих в Телеграм

При кого и защо са летели двете дружки? За героинята от първата част на това разследване Цилевич е известно, че в края на 90-те и в началото на 2000-е тя е била близка със Золотов. Това е бил интересен период от живота на настоящия ръководител на Росгвардията. Първоначално той вероятно е работил в онази фирма “Балтик Ескорт” при Роман Цепов, а още когато Путин става държавен глава, Золотов отива в Москва и оглавява президентската охрана. Именно в този момент животът на Кривоногих и Цилевич става почти огледален – те заедно летят до Москва и обратно, заедно стават собственички на бизнеси, почти едновременно стават майки. Цилевич потвърди пред “Проект”, че отдавна се познава с Кривоногих.

Двама души, които са наясно с приятелките, посочиха причината за полета на Кривоногих – тя е била близка с президента Путин. Познанството им е започнало още през 90-те, преди избирането на Путин за президент и е продължило в началото на 2000-е. Към края на миналото десетилетие тези отношения, по данните на “Проект”, по-скоро са приключили. Двама познати на Путин от 90-те на въпрос за Кривоногих реагираха многозначително – не отрекоха, че знаят за кого става дума, но категорично отказаха да говорят за нея: “Може и да съм чувал, но няма да говоря” и “По тази тема аз няма да говоря”.

Причината за тази тайнственост може да се състои в това, че Кривоногих има дъщеря, родена през 2003 г., в периода, когато Путин започва подготовката за първото в кариерата си преизбиране. В копията на документите, с които се запозна “Проект”, бащата на Елизавета Кривоногих не е посочен, известно е само презимето й – Владимировна.

а предизборната кампания през 2003 г. Владимир Путин се появи в компанията на съпругата си Людмила. През 2013 г. Те обявиха развода си. Снимка: kremlin.ru

Вече няколко години Елизавета живее под друга фамилия и акаунтите й в социалните мрежи са с измислени имена. Съдейки по портретните й снимки, с които “Проект” разполага, тя феноменално прилича на руския президент. До този извод стигна професор Хассан Угайл, директор на центъра за визуален анализ при университета Брадфорд, Великобритания. Извършеният от него компютърен анализ показа, че приликите на Путин и Кривоногих-младша са 70, 44%, като сходството над 75% означава, че на снимките е един и същи човек. “От това може да се направи изводът за възможно роднинство между тях”, се посочва в заключението на анализа, направен по поръчка на редакцията.

Част от заключението на директора на центъра за визуален анализ при университета Брадфорд Хассан Угайл за сходствата между Путин и дъщерята на Кривоногих. Снимка: Проект Медиа

“Проект” не публикува портрета на непълнолетната дъщеря на Кривоногих по етични съображения. След като Светлана Кривоногих получи въпросите на редакцията, дъщеря й изтри от акаунта си повече от снимките, на които лицето й може да бъде разгледано.

Дъщерята на Светлана Кривоногих в бизнес-джет. Снимка от акаунта й в Instagram

Потокът от активи и собствености, продължаващ да се излива към семейството на Кривоногих, само потвърждава версията, че тези хора са много важни за президента.

Всеобщата любимка

Кривоногих е закупила огромното си жилище на Каменния остров през 2004 г. от компания, която, естествено, е била свързана с банка “Россия”.

Сградата дом на Кривоногих. Снимка: Проект Медиа

Семейство Кривоногих е подпомогнато с друго жилище от Владимир Литвиненко – несменяемият ректор на Планинския университет (Горный университет с насоченост към устойчивото развитие на минерално-суровинния сектор на икономиката, бел.ред.), под ръководството на когото Путин е защитил дисертация. В структурата на университета влизат няколко общежития на Васильовския остров, включително и на улицата с необичайното име Шкиперский проток. В сградата в стил “сталински ампир” живеят не само студенти. В началото на 2000-е г. свързаната с този университет компания става собственик на редица помещения, а после ги продава като апартаменти. Част от тях са предоставени на преподаватели, а друга – на разни “не обикновени” граждани, като семейството на Роман Цепов или майката на Светлана Кривоногих.

Малко по-късно се появява още един благодетел, сега вече покойник, собственикът на “Балтийска медийна група” Олег Руднов. Някога той бе директор на петербургския “Пети канал”, където се сближава с Путин по времето на изборната кампания на Анатолий Собчак през 1996 г. Семейство Руднови е изпълнявало и изпълнява деликатни поръчки в интерес на президента: Руднов облагородява гроба на дядото на Путин в Подмосковието и купува родния дом на президента в Тверска област, а синът на Руднов притежава къща до Виборг, където вероятно е отдъхвал президентът.

През 2006 г. Руднов-старши купува 200 квадрата жилище и нежилищно помещение в най-известния район на Петербург – в самото начало на Болшая Морская улица, редом с изхода към Дворцовия площад. Двата обекта към 2008 г. са придобити от Кривоногих, като в нежилищното помещение тя после открива ресторант “Холст масло”.

На Светлана Кривоногих е помагал и друг приятел на Путин – виолончелистът, кръстник на дъщеря му Мария и миноритарен акционер в банка “Россия” Сергей Ролдугин. От “Панамските досиета” е известно, че през 2011 г. свързаната с виолончелиста фирма от Британските Вирджински острови е превела на управляващата “Игора” компания два заема на стойност около 200 млн. рубли с годишна супер-лихва от 1%. Към онзи момент собственикът на основния дял в “Игора” е бил укрит в анонимна кипърска офшорка, но по-скоро той е имал отношение към Кривоногих. Въпросът е в това, че чрез тази офшорка Светлана става собственик на 37-метровата яхта Al’doga, която поне веднъж е засичана да е акостирала в яхт-клуба “Лагуна” на Юрий Ковалчук на Ладожкото езеро. Сега такава яхта струва около 5, 4 млн. долара.

Всичкото имущество и бизнес-активите на семейство Кривоногих, открито от “Проект”, може да бъде оценено на 7, 7 млрд. рубли или около 100 млн. долара.
Когато кореспондентът на “Проект” позвъни на Кривоногих, тя каза, че не може да говори, като се оправда, че пътува с влак. После обеща да върне обаждане по-късно, но повече не вдигна слушалката и не отговаряше на съобщенията. Прессекретарят на президента Путин Дмитрий Песков заяви, че за пръв път чува името на Светлана Кривоногих.

Понякога семейство Кривоногих плават с яхтата и по Нева. Но до дома им на Каменния остров яхтата не може да стигне заради задръстването по марината, макар там да има собствен пристан за неголемите плавателни съдове. Да попаднат на този пристан имат само избраните – пътят към сушата е преграден от портичка с верига и катинар. “Входът е затворен”, пише на портата, оставен е телефон за контакт с охранителната компания, свързана с банка “Россия”.

Автори: Андрей Захаров, Роман Баданин – “Проект Медиа
Превод: Биволъ

За шофьорите и завоите

Post Syndicated from original http://www.gatchev.info/blog/?p=2334

Днес присъствах на разговор, който ми се запечати в ума. Безспорно тезата ми импонира, пристрастен съм към нея. Никога обаче не бях подозирал, че ще я видя толкова ясно и точно описана. Съдете ме…

За всеки случай съм сменил имената на описаните.

—-

Докато бързах към едни клиенти, ме привикаха за нещичко други, които ми бяха на път. Проблемът беше спешен, така че се отбих. За щастие се оказа само леко изваден от рутера кабел за Интернет. Докато го рестартирах за всеки случай, огледах познатата ми ситуация.

Типична българска фирмичка. Уморен шеф, който върши и всичката друга мъжка работа в офиса – в момента разтоварва автомобила отвън. Няколко момичета, които се гърбят здравата, че да изкарат хляба. И тихичко водят тревожни разговори дали няма да стегнат още локдауна и да им затворят фирмата – знаят, че шефът и да иска, няма пари да им плаща заплати, ако не работят. Една си е довела към осем-девет годишното момченце, от работата ще го води някъде. Друга, докато мери нещо по нещо, пустосва коронавируса и целия свят. Трета обяснява, че те политиците са виновни. Всички се съгласяват с нея, за да избухне само след миг спор кои политици и с какво точно, без работата да прекъсне и за миг. Не участва единствено майката – опитва се да изчисти от ръкава на хлапака си боята, която той е успял да събере неизвестно откъде.

– Миме бе, ти какво ще кажеш? Левите политици ли са прави, или десните? – сръчква я въпрос откъм съседното бюро. Тя вдига глава от ръкава на якенцето. Четири чифта очи се надяват мнението ѝ да наклони везните в някоя посока.

– Ми… Гошко, ти с какъв шофьор искаш да пътуваш? Такъв дето прави само леви завои, или такъв дето прави само десни?

Детето я изглежда с големи и недоумяващи очи. След това заявява:

– Мамо, ама то шофьор, дето прави само леви завои, доникъде няма да стигне! И само десни също!

– Кажи де, кажи.

– Ама те защо правят само едните завои? Заяло им е кормилото ли?

– Не, не им е заяло. Така смятат за правилно.

– Ама ако ще завиват само на едната страна, ще се въртят все на едно място! И наляво да е, и надясно! Няма значение на кое!

– Така е.

– … … … Значи тогава са малоумници!

– Гошо, не се говори така! Засрами се!

– Ама мамо, наистина са малоумници! Да кажа, че не са, значи да излъжа! Нали казваш, че не е хубаво да лъжа?

Майката извърта очи към тавана. Останалите момичета се подхилват.

– Не, не са малоумници. Просто… си имат съображения.

– Тогава аз трябва да съм малоумник, за да се кача да ме возят! Ако ще да е с беемве! – За момент в погледа на момченцето преминава мечта.

– А при какъв шофьор ще се качиш да те вози?

– Ами дето завива… ами… ами накъдето трябва! – Момченцето я изглежда тържествуващо.

Майката кимва и отново съсредоточава усилията си върху изцапания ръкав. Другите девойки обаче изглежда не са доволни.

– Абе Миме бе, няма ли да кажеш левите политици ли са прави, или десните?

Майката въздъхва и продължава да чисти ръкава.

Как наистина да получим електронна идентификация

Post Syndicated from Bozho original https://blog.bozho.net/blog/3659

Национална схема за електронна идентификация още няма, по ред причини, както съм описал тук. Но в даден момент следващата или по-следващата година все ще стане – изпълнителят ще изгради нещо по заданието, ще достави и лични карти, те ще имат чип и на чипа ще се записва удостоверение за електронна идентичност.

Само че когато това стане, няма автоматично да имаме лесно и удобно средство за електронна идентификация и електронното управление да тръгне по мед и масло. Това е едно от трудните неща в електронното управление – че като пуснеш поръчката, след две години не режеш лента, а хората не могат да видят ползите веднага. А в допълнение, някои грешки в изпълнението могат да значат пълен провал, а не просто нужда от закърпване.

Затова тези дни се замислих и реших да обобщя нещата, с които трябва да се внимава при изпълнението, за да не получим накрая едни безполезни пластики и всичко да трябва да започне отначало. Да, има детайлно техническо задание, но проблемите по-долу не са функция само на техническата реализация.

Четенето на личната карта – чипът трябва да може да бъде прочетен, иначе картата е безполезна. Би трябвало чиповете да позволяват контактен и безконтактен достъп – контактен, за използване на всички налични четци на електронни подписи тип „карта“ (които мисля са все по-малко), и безконтактен. Контактното четене е доста неудобно (макар в Естония да е било успешно благодарение на добра кампания за разпространяване на четци, сега сме в друга технологична „ера“) и поради това трябва да се обърне внимание на безконтактното като най-масовия начин за използване на картата. В Правилника за прилагане на Закона за електронната идентификация бяхме включили текстове, които да предвиждат идентификация чрез безконтактно четене на телефон, докато потребителят заявява услуга на компютър (или на телефона, разбира се).

Трябва изпълнителят да реализира този процес удобно, със стандартни приложения за различните мобилни операционни системи, така че процесът да бъде: 1. натискане на бутон „идентифицирай се“ при заявяване на услуга 2. Излизане на съобщение на телефона за очаквана идентификация 3. допиране на картата и написване на PIN (може и в обратен ред, за по-голямо удобство) 4. Успешна идентификация. Трябва да се обърне внимание и на сигурността на безконтакното четене. Към 2016 стандартите по темата не бяха масово възприети, така че изпълнителят и възложителят трябва да преценят кой е най-актуалният начин.

Персонализиране на други носители – електронната идентификация не е само „чип в личната карта“. Всъщност чипът в личната карта е само една от много възможности. Трябва в рамките на издаването на удостоверение за електронна идентичност да се даде опция за записването му (заедно с частния ключ) на смартфон или на друга карта. Записването на частен ключ на телефон към 2016 г. не беше сигурно (имаше известни атаки), но 4 години по-късно вече е. И в нормативната уредба, и в заданието е заложена възможност за издаване на eID чрез вече съществуващо eID. Т.е. може с еднократно използване на личната карта да се създаде нов частен ключ и удостоверение на телефона и всяка следваща идентификация да не изисква докосване на картата и писане на PIN (а използване на сензора за пръстов отпечатък). Тези опции са заложени и напълно възможни, но трябва и възложителят, и изпълнителят да съблюдават те да се случат по този начин.

Електронно подписванемежду електронна идентификация и електронен подпис има съществена разлика (едното е „да си покажеш личната карта“, другото е „да се подпишеш“). Много услуги изискват подпис за заявяване (или за попълване на някоя декларация), което би направило електронната идентификация почти безполезна, с изключение на някои справочни услуги. Именно затова е ключов чл. 22, ал. 5 от Закона за електронното управление, изрично позволяващ заявяването на услуги от физически лица да се допустимо с неквалифициран електронен подпис (а с усъвършенстван). На практика това значи, че всяка съществуваща и бъдеща услуга трябва да може да бъде подписвана със същите криптографски ключове (или производни на тях), използвани за електронната идентификация.

Това би представлявало усъвършенстван електронен подпис и няма да се налага освен личната карта да имате и квалифициран електронен подпис (още повече, че преди 2 години законодателят махна опцията личните карти да поддържат електронни подписи, не е много ясно защо, освен може би заради техническите изисквания към чиповете). Европейската Комисия изрично посочва, че държавите членки определят с какъв вид подпис могат да се ползват административни услуги, та ние се възползвахме от тази опция. Има и още една опция, но тя е по-трудна – да се променят всички закони, наредби, правилници, заповеди и вътрешни правила и навсякъде да се посочи, че не се изисква подпис за електронно заявяване. Но това е непрактично и крие рискове.

Дори картата (и приложението на смартфона) да могат да слагат криптографски подпис, това няма да е достатъчно. Съществуващи услуги, използващи различни средства за подписване, ще трябва да бъдат интегрирани. Може да се наложи дори разработване на специален драйвер, който настоящите аплети и приложения за подписване да заредят, за да бъде опакован криптографския подпис от смарткартата в електронен подпис по смисъла на законодателството. Тези процеси трябва да бъдат разписани и изтествани.

Интеграция на системи – в рамките на проекта трябва да бъдат изготвени компоненти за лесна интеграция на системи. Никоя система няма по подразбиране да поддържа електронната идентификация и трябва бързо да могат да се надградят. Т.нар. SDK, примерен код на различни езици и стандартни приложения за различни операционни системи (десктоп и мобилни) са част от техническото задание, но на тях трябва да бъде обърнато особено внимание – в противен случай ще имаме в джоба си нещо, което не можем да използваме никъде.

Извън самия проект, трябва останалите институции да са подготвени за това – да имат разписани малки проекти за надграждане на съществуващи системи, така че да интегрират електронната идентификация. Това може да става дори паралелно с изграждането на системата за електронна идентификация, защото стандартите за комуникация са ясни, а някои части от проекта ще бъдат доставени преди неговия край.

Не на последно място, трябва да бъде реализирана идентификация на юридически лица чрез връзка в реално време с Търговския регистър (и РЮЛНЦ, и Булстат), за да се избегнат проблемите, които произтичат от настоящото решение с КЕП. Това предполага надграждане на системи и понякога промяна на процеси.

Цялостна архитектура на федерираната идентификация – националната схема за електронна идентификация е само една от няколко опции. Вече има частни схеми за идентификация, отдавна има всевъзможни ПИК-ове, които макар и от ниско ниво, минават за идентификация по Регламент 910/2014. Има и необходимост да се поддържат електронните идентификации на всички държави членки. Трябва максимално бързо да бъде разписана архитектура на федерирана идентификация, която да позволява на гражданите да ползват всяка услуга с подходящо за целта средство. Първо, с надграждането на административния регистър (което също трябваше да е станало отдавна) трябва да се добавят нивата на осигуреност на идентификацията, която дадена услуга изисква. След това трябва да има т.нар. eIDAS възел, който да позволява интеграция с европейските схеми.

Трябва да бъде подготвена архитектура и на местно ниво – как частни схеми и/или частни центрове за електронна идентификация да си общуват с националната схема. Къде в картинката стои и настоящата система за е-автентикация на ДАЕУ, която от временно решение се превръща във все по-устойчиво такова. За щастие всички тези системи „говорят“ (и трябва да говорят според нормативните изисквания) на един „език“ – протоколът SAML 2.0. Но кой кого извиква, с какви параметри, кой какви регистри държи и какво позволява; как се извършва подписване при схеми, които не са националната (напр. чрез съхраняване на SAML 2.0 assertions) и не на последно място – как да бъде осъвременена нормативната уредба с всичко това. Сложни въпроси, които трябва да намерят отговор в следващите 6 месеца, за да не се окажем в батак, в който всичко е толкова фрагментирано, че много малко хора да могат да ползват услугите, които искат със средството за идентификация, което имат.

Може би стана прекалено техническо, но дяволът е в детайлите. Ако объркаме някой от тези детайли, рискуваме да продължим да трупаме изоставане в електронното управление, а закъснялата електронна идентификация да не донесе позитивните резултати, с каквито очаквания е натоварена.

Материалът Как наистина да получим електронна идентификация е публикуван за пръв път на БЛОГодаря.

Building Black Friday e-commerce experiences with JAMstack and Cloudflare Workers

Post Syndicated from Kristian Freeman original https://blog.cloudflare.com/building-black-friday-e-commerce-experiences-with-jamstack-and-cloudflare-workers/

Building Black Friday e-commerce experiences with JAMstack and Cloudflare Workers

The idea of serverless is to allow developers to focus on writing code rather than operations — the hardest of which is scaling applications. A predictably great deal of traffic that flows through Cloudflare’s network every year is Black Friday. As John wrote at the end of last year, Black Friday is the Internet’s biggest online shopping day. In a past case study, we talked about how Cordial, a marketing automation platform, used Cloudflare Workers to reduce their API server latency and handle the busiest shopping day of the year without breaking a sweat.

The ability to handle immense scale is well-trodden territory for us on the Cloudflare blog, but scale is not always the first thing developers think about when building an application — developer experience is likely to come first. And developer experience is something Workers does just as well; through Wrangler and APIs like Workers KV, Workers is an awesome place to hack on new projects.

Over the past few weeks, I’ve been working on a sample open-source e-commerce app for selling software, educational products, and bundles. Inspired by Humble Bundle, it’s built entirely on Workers, and it integrates powerfully with all kinds of first-class modern tooling: Stripe, an API for accepting payments (both from customers and to authors, as we’ll see later), and Sanity.io, a headless CMS for data management.

This kind of project is perfectly suited for Workers. We can lean into Workers as a static site hosting platform (via Workers Sites), API server, and webhook consumer, all within a single codebase, and deployed instantly around the world on Cloudflare’s network.

If you want to see a deployed version of this template, check out ecommerce-example.signalnerve.workers.dev.

Building Black Friday e-commerce experiences with JAMstack and Cloudflare Workers
The frontend of the e-commerce Workers template.

In this blog post, I’ll dive deeper into the implementation details of the site, covering how Workers continues to excel as a JAMstack deployment platform. I’ll also cover some new territory in integrating Workers with Stripe. The project is open-source on GitHub, and I’m actively working on improving the documentation, so that you can take the codebase and build on it for your own e-commerce sites and use cases.

The frontend

As I wrote last year, Workers continues to be an amazing platform for JAMstack apps. When I started building this template, I wanted to use some things I already knew — Sanity.io for managing data, and of course, Workers Sites for deploying — but some new tools as well.

Workers Sites is incredibly simple to use: just point it at a directory of static assets, and you’re good to go. With this project, I decided to try out Nuxt.js, a Vue-based static site generator, to power the frontend for the application.

Using Sanity.io, the data representing the bundles (and the products inside of those bundles) is stored on Sanity.io’s own CDN, and retrieved client-side by the Nuxt.js application.

Building Black Friday e-commerce experiences with JAMstack and Cloudflare Workers
Managing data inside Sanity.io’s headless CMS interface.

When a potential customer visits a bundle, they’ll see a list of products from Sanity.io, and a checkout button provided by Stripe.

Responding to new checkout sessions and purchases

Making API requests with Stripe’s Node SDK isn’t currently supported in Workers (check out the GitHub issue where we’re discussing a fix), but because it’s just REST underneath, we can easily make REST requests using the library.

When a user clicks the checkout button on a bundle page, it makes a request to the Cloudflare Workers API, and securely generates a new session for the user to checkout with Stripe.

import { json, stripe } from '../helpers'

export default async (request) => {
  const body = await request.json()
  const { price_id } = body

  const session = await stripe('/checkout/sessions', {
    payment_method_types: ['card'],
    line_items: [{
        price: price_id,
        quantity: 1,
      }],
    mode: 'payment'
  }, 'POST')

  return json({ session_id: session.id })
}

This is where Workers excels as a JAMstack platform. Yes, it can do static site hosting, but with just a few extra lines of routing code, I can deploy a highly scalable API right alongside my Nuxt.js application.

Webhooks and working with external services

This idea extends throughout the rest of the checkout process. When a customer is successfully charged for their purchase, Stripe sends a webhook back to Cloudflare Workers. In order to complete the transaction on our end, the Workers application:

  • Validates the incoming data from Stripe to ensure that it’s legitimate. This means that every incoming webhook request is explicitly validated using your Stripe account details, and can be confirmed to be valid before the function acts on it.
  • Distributes payments to the authors using Stripe Connect. When a customer buys a bundle for $20, that $20 (minus Stripe fees) gets distributed evenly between the authors in that bundle — all of this calculation and the associated transfer requests happen inside the Worker.
  • Sends a unique download link to the customer. Using Workers KV, a unique token is set up that corresponds to the customer’s email, which can be used to retrieve the content the customer purchased. This integration uses Mailgun to construct an email and send it entirely over REST APIs.

By the time the purchase is complete, the Workers serverless API will have interfaced with four distinct APIs, persisting records, sending emails, and handling and distributing payments to everyone involved in the e-commerce transaction. With Workers, this all happens in a single codebase, with low latency and a superb developer experience. The entire API is type-checked and validated before it ever gets shipped to production, thanks to our TypeScript template.

Building Black Friday e-commerce experiences with JAMstack and Cloudflare Workers

Each of these tasks involves a pretty serious level of complexity, but by using Workers, we can abstract each of them into smaller pieces of functionality, and compose powerful, on-demand, and infinitely scalable webhooks directly on the serverless edge.

Conclusion

I’m really excited about the launch of this template and, of course, it wouldn’t have been possible to ship something like this in just a few weeks without using Cloudflare Workers. If you’re interested in digging into how any of the above stuff works, check out the project on GitHub!

With the recent announcement of our Workers KV free tier, this project is perfect to fork and build your own e-commerce products with. Let me know what you build and say hi on Twitter!

Backing Up Our Thanks

Post Syndicated from Ramya Ramamoorthy original https://www.backblaze.com/blog/backing-up-our-thanks/

Needless to say, 2020 has been a challenging, unpredictable year for everyone. All of us faced trials that we had never expected a year ago. In spite of the adversity, or possibly simply to ward it off, our team decided to dig for a couple of silver linings from this past year. We understand that times are still tough, but we wanted to take a moment this Thanksgiving season to show thanks for some of the unexpected positives that have come out of quarantine.

So we reached out to the team to see what goodness they’ve taken from what has felt like a terrible, horrible, no good, very bad year (hat tip to Judith Viorst), and we got some excellent responses that we’ve digested for you here.

Healthier Lifestyles

Many of our team members have exchanged their morning commute for a workout. Jeremy, our Senior Director of Product Marketing, has run far more track and trail miles, more often and more quickly over time. He even set a 5K personal record time!

Yev, our Director of Marketing, has also been on the workout grind. He said, “I’ve lost weight and gotten more healthy! During the first day of shelter-in-place, I started doing yoga and a small calisthenic workout, and have kept that streak going throughout the pandemic. I’ve also started to walk four to five miles per day to get me to the 10K step mark, and have started to eat more vegetables. Gross! But also, great!”

Photo by Jenny Hill.

It’s a Full House

No matter the family size you have, before the pandemic, many of us were a little bit busy and hard to catch up with. But, shelter-in-place gave us the opportunity (and sometimes the necessity) to slow down and reconnect with family and friends over Zoom happy hours and holiday celebrations.

Those family members who were long distance and couldn’t make it to all the holidays finally got to join in and see everyone on the screen. College friends who kept pushing out that weekend getaway together found a way to play virtual games and share silly memories with each other.

One common response that people gave about this shelter-in-place time is that “It’s time we won’t ever get to spend together like this again.” Although our new work from home coworkers took up a lot of the Wi-Fi bandwidth, we wouldn’t trade that time we spent at home with family, friends, and kids for anything else.

Photo by Pablo Merchán Montes.

Furry Friends to the Rescue

Let’s admit it, animals truly love their owners unconditionally (even cats, in their own special way) and that makes leaving them behind in a house all day tough. Some days it’s hard when your animal accidentally falls asleep on your toes and you just don’t have the heart to move them when it’s time to leave for work. The pandemic has made that conundrum a tad easier.

During shelter-in-place, having an animal nearby during tough times made life a lot easier to deal with. The potential for impending bad news each day made a cuddly dog or an energetic hamster an important part of the survival kit for each day for many of us.

And for the animals, this time at home was a blessing. They didn’t know why they had been given it but it was pretty cool that it was happening. They didn’t need to know about social distancing, or what the right face mask to wear is, or how to disinfect their groceries—animals just saw this time as extra time with their owners. They couldn’t believe they were around… and around… and still there… and “OMG they are still there.”

Seeing the world through their eyes of “more play time” really made shelter-in-place a little less tough.

Photo by Adrianna Calvo.

Cozy Pants Rule

With work from home, employees have embraced clothing that makes them feel more comfortable. Judith, our Recruiting Coordinator, said, “During shelter-in-place I’ve completely given up wearing jeans, and other restricting (yet, fashionable) items. I don’t think I’ll ever go back. I am so happy with my decision. Goodbye, jeans! See you never.”

Cheers to a lifetime of no more jeans!

Photo by Tatiana Syrikova.

No Traffic!

Although we miss being able to binge our favorite podcasts in the car, we do not miss sitting in car-to-car traffic. One of the top responses we found from our coworkers about silver linings during shelter-in-place is “Getting back two hours of my day that I used to spend commuting!”

If you sit in two hours of traffic a week for an average of 10 hours a week—that amounts to nearly 20 days in a year that we get back. And to top it off, driving to go anywhere at 5 p.m. is less stressful when you don’t have to worry about rush hour traffic.

Photo by Nick Fewings.

Some “Me” Time

Even though the pandemic has led to fewer social interactions, some of our employees have been enjoying that alone time. They have a lot more freedom to do what they want; for example, some of our employees love that they can now listen to music while working without wearing headphones.

Another silver lining for some of our coworkers is that they no longer have to attend social events, which has been a real stress inducer for them in the past. We still have virtual social events for our extroverted employees, but this time in quarantine has given our introverted employees a bit of a breather.

Photo by Andrea Piacquadio.

Share Your Silver Lining!

We’ve watched the world find new ways to bring each other together in a year where it felt like we could never be close again. Out of adversity we found new ways to connect, be creative, care for others, and also make a lot of new food (Like sourdough, who doesn’t love a good homemade sourdough loaf?).

We hope that you can find a silver lining in your 2020, too. Whether it be big, or small, or something in between. Also, thank you to Nicole Perry for help with writing this post!

We’d love for you to join us and find your own silver lining at Backblaze. We’re hiring, so apply today! We wish you and your loved ones a happy Thanksgiving!

The post Backing Up Our Thanks appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

Умиранията в България 2010-2020 г.

Post Syndicated from original https://yurukov.net/blog/2020/smartnost-2020/

Една от метриките, които най-много се следи в сегашната пандемия, са смъртните случаи. Има доста спорове дали наистина са повече, дали са с или заради коронавирус, дали са причинени от самата пандемия или трагичен страничен ефект от паниката и ограниченията покрай нея.

На тези въпроси трудно може да отговорим, защото нямаме достатъчно данни, а и яснота относно съществуващите. Може да разглеждаме това, което имам обаче и да ги си правим собствени изводи. Затова наскоро представих по нов начин умиранията в България в опит да помогна да се осмисли разликата с предходни години по-добре. Пуснах няколко снимки миналата седмица, а тук ще намерите интерактивната версия с последните данни.

Преди да минем към нея, ще ви насоча към няколко полезни източника. На първо време това е EuroMOMO, които за съжаление въпреки усилията на някои в НЦЗПБ през годините и доста хора от началото на тази година, все още не са добавили данните от България към модела си. Може обаче да видите индекса им за excessive mortality, разработен за грипа и показващ сега ефекта от коронавирус. Отделно данните по-долу са взети от Eurostat, където НСИ публикува разбивка на умиранията по седмици, пол, възраст и области. Страницата на НСИ специално за смъртността заедно с тяхното сравнение с предишни години също е полезна.

Макар тук да говорим конкретно за смъртност в кратък период от време и конкретен контекст, важно е да се разбере, че този аспект от демографията е доста сложен като процеси и зависимости. Затова ще ви насоча към предишни текстове, където го разглеждам:

Кръгова графика на умиранията

Тъй като има ясно разпознаваема цикличност в смъртността, реших да представя умиранията не в линейна графика, както НСИ, а като кръгова. Също добавих последните 10 години по седмици и възможност да се избират отделни възрастови групи от 0 до 90+.

Макар така да не може да се различи отделна година, се вижда ясно тенденциите в последното десетилетие и как тази година се различава от тях. Виждаме, например, че възрастните хора между 70 и 75 г. са били особено тежко засегнати и смъртността сред тях е била по-висока спрямо предходните години още от началото на пандемията. Всъщност, смъртността при всички между 50 и 80 е по-висока от дори най-сериозния пик в последните 10 години.

Графиката започва с анимация, която може да се включва и изключва за всеки филтър. Може също да се сменя между абсолютен брой умирания и смъртност на милион души население. Отделно по вертикалата за прегледност не започва гафиката от 0, но може да го включите, ако предпочитате така.

В тези данни не съм включил само данните за смъртните случаи, за които е установено, че са от коронавирус. Не съм включил и данните за заболеваемостта и карантинираните. Нямах възможност да добавя и филтър по пол и област, а и не исках да се претоварва графиката. Показват всички смъртни случаи от всички причини. За агрегирането на информацията за последните трябва доста време и евентуално ще я получим едва догодина.

Целта ми е единствено да покажа данните и графиката на НСИ по нов начин. Така, според мен, се поставя в по-ясен контекст от една драстичното увеличение, което наблюдаваме, а от друга – нетипичното време от годината.

The post Умиранията в България 2010-2020 г. first appeared on Блогът на Юруков.

Thanksgiving security updates

Post Syndicated from original https://lwn.net/Articles/838397/rss

Security updates have been issued by openSUSE (blueman, chromium, firefox, LibVNCServer, postgresql10, postgresql12, thunderbird, and xen), Slackware (bind), SUSE (bluez, kernel, LibVNCServer, thunderbird, and ucode-intel), and Ubuntu (mutt, poppler, thunderbird, and webkit2gtk).

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close