Industry Buzz

Now Open – Third Availability Zone in the AWS Canada (Central) Region

Amazon Web Services Blog -

When you start an EC2 instance, it’s easy to underestimate what an AWS Region is. Right now, we have 22 across the world, and while they look like dots on a global map, they are architected to let you run applications and store data with high availability and fault tolerance. In fact, each of our Regions is made up of multiple data centers, which are geographically separated into what we call Availability Zones (AZs). Today, I am very happy to announce that we added a third AZ to the AWS Canada (Central) Region to support our customer base in Canada. It’s important to notice that Amazon S3 storage classes that replicate data across a minimum of three AZs, are always doing so, even when fewer than three AZs are publicly available. This third AZ provides customers with additional flexibility to architect scalable, fault-tolerant, and highly available applications, and will support additional AWS services in Canada. We opened the Canada (Central) Region in December 2016, just over 3 years ago, and we’ve more than tripled the number of available services as we bring on this third AZ. Each AZ is in a separate and distinct geographic location with enough distance to significantly reduce the risk of a single event impacting availability in the Region, yet near enough for business continuity applications that require rapid failover and synchronous replication. For example, our Canada (Central) Region is located in the Montreal area of Quebec, and the upcoming new AZ will be on the mainland more than 45 kms/28 miles away from the next-closest AZ as the crow flies. Where we place our Regions and AZs is a deliberate and thoughtful process that takes into account not only latency or distance, but also risk profiles. To keep the risk profile low, we look at decades of data related to floods and other environmental factors before we settle on a location. Montreal was heavily impacted in 1998 by a massive ice storm that crippled the power grid and brought down more than 1,000 transmission towers, leaving four million people in neighboring provinces and some areas of New York and Maine without power. In order to ensure that AWS infrastructure can withstand inclement weather such as this, half of the AZs interconnections use underground cables and are out of the impact of potential ice storms. In this way, every AZ is connected to the other two AZs by at least one 100% underground fiber path. We’re excited to bring a new AZ to Canada to serve our incredible customers in the region. Here are some examples from different industries, courtesy of my colleagues in Canada: Healthcare – AlayaCare delivers cloud-based software to home care organizations across Canada and all over the world. As a home healthcare technology company, they need in-country data centers to meet regulatory requirements. Insurance – Aviva is delivering a world-class digital experience to its insurance clients in Canada and the expansion of the AWS Region is welcome as they continue to move more of their applications to the cloud. E-Learning – D2L leverages various AWS Regions around the world, including Canada to deliver a seamless experience for their clients. They have been on AWS for more than four years, and recently completed an all-in migration. With this launch, AWS has now 70 AZs within 22 geographic Regions around the world, plus 5 new regions coming. We are continuously looking at expanding our infrastructure footprint globally, driven largely by customer demand. To see how we use AZs in Amazon, have look at this article on Static stability using Availability Zones by Becky Weiss and Mike Furr. It’s part of the Amazon Builders’ Library, a place where we share what we’ve learned over the years. For more information on our global infrastructure, and the custom hardware we use, check out this interactive map. — Danilo Une troisième zone de disponibilité pour la Région AWS Canada (Centre) est lancée Lorsque vous lancez une instance EC2, il est facile de sous-estimer l’étendue d’une région infonuagique AWS. À l’heure actuelle, nous avons 22 régions dans le monde. Bien que ces dernières ne ressemblent qu’à des petits points sur une grande carte, elles sont conçues pour vous permettre de lancer des applications et de stocker des données avec une grande disponibilité et une tolérance aux pannes. En fait, chacune de nos régions comprend plusieurs centres de données distincts, regroupés dans ce que nous appelons des zones de disponibilités. Aujourd’hui, je suis très heureux d’annoncer que nous avons ajouté une troisième zone de disponibilité à la Région AWS Canada (Centre) afin de répondre à la demande croissante de nos clients canadiens. Il est important de noter que que les classes de stockage Amazon S3 qui répliquent des données à travers au moins trois zones de disponibilité, le font toujours, même lorsque moins de trois zones de disponibilité sont accessibles publiquement. Cette troisième zone de disponibilité offre aux clients une souplesse additionnelle, leur permettant de concevoir des applications évolutives, tolérantes et hautement disponibles. Cette zone de disponibilité permettra également la prise en charge d’un plus grand nombre de services AWS au Canada. Nous avons ouvert la région infonuagique en décembre 2016, il y a un peu plus de trois ans, et nous avons plus que triplé le nombre de services disponibles en lançant cette troisième zone. Chaque zone de disponibilité AWS se situe dans un lieu géographique séparé et distinct, suffisamment éloignée pour réduire le risque qu’un seul événement puisse avoir une incidence sur la disponibilité dans la région, mais assez rapproché pour permettre le bon fonctionnement d’applications de continuité d’activités qui nécessitent un basculement rapide et une réplication synchrone. Par exemple, notre Région Canada (Centre) se situe dans la région du grand Montréal, au Québec. La nouvelle zone de disponibilité sera située à plus de 45 km à vol d’oiseau de la zone de disponibilité la plus proche. Définir l’emplacement de nos régions et de nos zones de disponibilité est un processus délibéré et réfléchi, qui tient compte non seulement de la latence/distance, mais aussi des profils de risque. Par exemple, nous examinons les données liées aux inondations et à d’autres facteurs environnementaux sur des décennies avant de nous installer à un endroit. Ceci nous permet de maintenir un profil de risque faible. En 1998, Montréal a été lourdement touchée par la tempête du verglas, qui a non seulement paralysé le réseau électrique et engendré l’effondrement de plus de 1 000 pylônes de transmission, mais qui a également laissé quatre millions de personnes sans électricité dans les provinces avoisinantes et certaines parties dans les états de New York et du Maine. Afin de s’assurer que l’infrastructure AWS résiste à de telles intempéries, la moitié des interconnexions câblées des zones de disponibilité d’AWS sont souterraines, à l’abri des tempêtes de verglas potentielles par exemple. Ainsi, chaque zone de disponibilité est reliée aux deux autres zones par au moins un réseau de fibre entièrement souterrain. Nous nous réjouissons d’offrir à nos clients canadiens une nouvelle zone de disponibilité pour la région. Voici quelques exemples clients de différents secteurs, gracieuseté de mes collègues canadiens : Santé – AlayaCare fournit des logiciels de santé à domicile basés sur le nuage à des organismes de soins à domicile canadiens et partout dans le monde. Pour une entreprise de technologie de soins à domicile, le fait d’avoir des centres de données au pays est essentiel et lui permet de répondre aux exigences réglementaires. Assurance – Aviva offre une expérience numérique de classe mondiale à ses clients du secteur de l’assurance au Canada. L’expansion de la région AWS est bien accueillie alors qu’ils poursuivent la migration d’un nombre croissant de leurs applications vers l’infonuagique. Apprentissage en ligne – D2L s’appuie sur diverses régions dans le monde, dont celle au Canada, pour offrir une expérience homogène à ses clients. Ils sont sur AWS depuis plus de quatre ans et ont récemment effectué une migration complète. Avec ce lancement, AWS compte désormais 70 zones de disponibilité dans 22 régions géographiques au monde – et cinq nouvelles régions à venir. Nous sommes continuellement à la recherche de moyens pour étendre notre infrastructure à l’échelle mondiale, entre autres en raison de la demande croissante des clients. Pour comprendre comment nous utilisons les zones de disponibilité chez Amazon, consultez cet article sur la stabilité statique à l’aide des zones de disponibilité par Becky Weiss et Mike Furr. Ce billet se retrouve dans la bibliothèque des créateurs d’Amazon, un lieu où nous partageons ce que nous avons appris au fil des années. Pour plus d’informations sur notre infrastructure mondiale et le matériel informatique personnalisé que nous utilisons, consultez cette carte interactive. — Danilo

Introducing Quicksilver: Configuration Distribution at Internet Scale

CloudFlare Blog -

Cloudflare’s network processes more than fourteen million HTTP requests per second at peak for Internet users around the world. We spend a lot of time thinking about the tools we use to make those requests faster and more secure, but a secret-sauce which makes all of this possible is how we distribute configuration globally. Every time a user makes a change to their DNS, adds a Worker, or makes any of hundreds of other changes to their configuration, we distribute that change to 200 cities in 90 countries where we operate hardware. And we do that within seconds. The system that does this needs to not only be fast, but also impeccably reliable: more than 26 million Internet properties are depending on it. It also has had to scale dramatically as Cloudflare has grown over the past decade.Historically, we built this system on top of the Kyoto Tycoon (KT) datastore. In the early days, it served us incredibly well. We contributed support for encrypted replication and wrote a foreign data wrapper for PostgreSQL. However, what worked for the first 25 cities was starting to show its age as we passed 100. In the summer of 2015 we decided to write a replacement from scratch. This is the story of how and why we outgrew KT, learned we needed something new, and built what was needed.How KT Worked at CloudflareWhere should traffic to example.com be directed to?What is the current load balancing weight of the second origin of this website?Which pages of this site should be stored in the cache?These are all questions which can only be answered with configuration, provided by users and delivered to our machines around the world which serve Internet traffic. We are massively dependent on our ability to get configuration from our API to every machine around the world.It was not acceptable for us to make Internet requests on demand to load this data however, the data had to live in every edge location. The architecture of the edge which serves requests is designed to be highly failure tolerant. Each data center must be able to successfully serve requests even if cut off from any source of central configuration or control.Our first large-scale attempt to solve this problem relied on deploying Kyoto-Tycoon (KT) to thousands of machines. Our centralized web services would write values to a set of root nodes which would distribute the values to management nodes living in every data center. Each server would eventually get its own copy of the data from a management node in the data center in which it was located:Data flow from the API to data centres and individual machinesDoing at least one read from KT was on the critical path of virtually every Cloudflare service. Every DNS or HTTP request would send multiple requests to a KT store and each TLS handshake would load certificates from it. If KT was down, many of our services were down, if KT was slow, many of our services were slow. Having a service like KT was something of a superpower for us, making it possible for us to deploy new services and trust that configuration would be fast and reliable. But when it wasn’t, we had very big problems.As we began to scale one of our first fixes was to shard KT into different instances. For example, we put Page Rules in a different KT than DNS records. In 2015, we used to operate eight such instances storing a total of 100 million key-value (KV) pairs, with about 200 KV values changed per second. Across our infrastructure, we were running tens of thousands of these KT processes. Kyoto Tycoon is, to say the least, very difficult to operate at this scale. It’s clear we pushed it past its limits and for what it was designed for.To put that in context it’s valuable to look back to the description of KT provided by its creators:[It] is a lightweight datastore server with auto expiration mechanism, which is useful to handle cache data and persistent data of various applications. (http://fallabs.com/kyototycoon/)It seemed likely that we were not uncovering design failures of KT, but rather we were simply trying to get it to solve problems it was not designed for. Let’s take a deeper look at the issues we uncovered.Exclusive write lock… or not?To talk about the write lock it’s useful to start with another description provided by the KT documentation:Functions of API are reentrant and available in multi-thread environment. Different database objects can be operated in parallel entirely. For simultaneous operations against the same database object, rwlock (reader-writer lock) is used for exclusion control. That is, while a writing thread is operating an object, other reading threads and writing threads are blocked. However, while a reading thread is operating an object, reading threads are not blocked. Locking granularity depends on data structures. The hash database uses record locking. The B+ tree database uses page locking.On first glance this sounds great! There is no exclusive write lock over the entire DB. But there are no free lunches; as we scaled we started to detect poor performance when writing and reading from KT at the same time.In the world of Cloudflare, each KT process replicated from a management node and was receiving from a few writes per second to a thousand writes per second. The same process would serve thousands of read requests per second as well. When heavy write bursts were happening we would notice an increase in the read latency from KT. This was affecting production traffic, resulting in slower responses than we expect of our edge.Here are the percentiles for read latency of a script reading from KT the same 20 key/value pairs in an infinite loop. Each key and each value is 2 bytes.  We never update these key/value pairs so we always get the same value.Without doing any writes, the read performance is somewhat acceptable even at high percentiles:P99: 9msP99.9: 15msWhen we add a writer sequentially adding a 40kB value, however, things get worse. After running the same read performance test, our latency values have skyrocketed:P99: 154msP99.9: 250msAdding 250ms of latency to a request through Cloudflare would never be acceptable. It gets even worse when we add a second writer, suddenly our latency at the 99.9th percentile (the 0.1% slowest reads) is over a second!P99: 701msP99.9: 1215msThese numbers are concerning: writing more increases the read latency significantly. Given how many sites change their Cloudflare configuration every second, it was impossible for us to imagine a world where write loads would not be high. We had to track down the source of this poor performance. There must be either resource contention or some form of write locking, but where?The Lock HuntAfter looking into the code the issue seems to be that when reading from KT, the function accept in the file kcplandb.h of Kyoto Cabinet acquires a lock:This lock is also acquired in the synchronize function of kcfile.cc in charge of flushing data to disk:This is where we have a problem. Flushing to disk blocks all reads and flushing is slow.So in theory the storage engine can handle parallel requests but in reality we found at least one place where this is not true. Based on this and other experiments and code review we came to the conclusion that KT was simply not designed for concurrent access. Due to the exclusive write lock implementation of KT, I/O writes degraded read latency to unacceptable levels.In the beginning, the occurrence of that issue was rare and not a top priority. But as our customer base grew at rocket speed, all related datasets grew at the same pace. The number of writes per day was increasing constantly and this contention started to have an unacceptable impact on performance.As you can imagine our immediate fix was to do less writes. We were able to make small-scale changes to writing services to reduce their load, but this was quickly eclipsed by the growth of the company and the launch of new products. Before we knew it, our write levels were right back to where they began!As a final step we disabled the fsync which KT was doing on each write. This meant KT would only flush to disk on shutdown, introducing potential data corruption which required its own tooling to detect and repair.Unsynchronized SwimmingContinuing our theme of beginning with the KT documentation, it’s worth looking at how they discuss non-durable writes:If an application process which opened a database terminated without closing the database, it involves risks that some records may be missing and the database may be broken. By default, durability is settled when the database is closed properly and it is not settled for each updating operation.At Cloudflare scale, kernel panics or even processor bugs happen and unexpectedly kill services. By turning off syncing to improve performance we began to experience database corruption. KT comes with a mechanism to repair a broken DB which we used successfully at first. Sadly, on our largest databases, the rebuilding process took a very long time and in many cases would not complete at all. This created a massive operational problem for our SRE team.Ultimately we turned off the auto-repair mechanism so KT would not start if the DB was broken and each time we lost a database we copied it from a healthy node. This syncing was being done manually by our SRE team. That team’s time is much better spent building systems and investigating problems; the manual work couldn’t continue.Not syncing to disk caused another issue: KT had to flush the entire DB when it was being shut down. Again, this worked fine at the beginning, but with the DB getting bigger and bigger, the shut down time started to sometimes hit the systemd grace period and KT was terminated with a SIGKILL. This led to even more database corruption.Because all of the KT DB instances were growing at the same pace, this issue went from minor to critical seemingly overnight. SREs wasted hours syncing DBs from healthy instances before we understood the problem and greatly increased the grace period provided by systemd.We also experienced numerous random instances of database corruption. Too often KT was shut down cleanly without any error but when restarted the DB was corrupted and had to be restored. In the beginning, with 25 data centers, it happened rarely. Over the years we added thousands of new servers to Cloudflare infrastructure and it was occurring multiple times a day.Writing MoreMost of our writes are adding new KV pairs, not overwriting or deleting. We can see this in our key count growth:In 2015, we had around 100 million KV pairsIn 2017, we passed 200 millionIn 2018, we passed 500 millionIn 2019, we exceeded 1 billionUnfortunately in a world where the quantity of data is always growing, it’s not realistic to think you will never flush to disk. As we write new keys the page cache quickly fills. When it’s full, it is flushed to disk. I/O saturation was leading to the very same contention problems we experienced previously.Each time KT received a heavy write burst, we could see the read latency from KT increasing in our DC. At that point it was obvious to us that the KT DB locking implementation could no longer do the job for us with or without syncing. Storage wasn’t our only problem however, the other key function of KT and our configuration system is replication.The Best Effort Replication ProtocolKT replication protocol is based solely on timestamp. If a transaction fails to replicate for any reason but it is not detected, the timestamp will continue to advance forever missing that entry.How can we have missing log entries? KT replicates data by sending an ordered list of transaction logs. Each log entry details what change is being made to our configuration database. These logs are kept for a period of time, but are eventually ‘garbage collected’, with old entries removed.Let’s think about a KT instance being down for days, it then restarts and asks for the transaction log from the last one it got. The management node receiving the request will send the nearest entries to this timestamp, but there could be missing transaction logs due to garbage collection. The client would not get all the updates it should and this is how we quietly end up with an inconsistent DB.Another weakness we noticed happens when the timestamp file is being written. Here is a snippet of the file ktserver.cc where the client replication code is implemented:This code snippet runs the loop as long as replication is working fine. The timestamp file is only going to be written when the loop terminates. The call to write_rts (the function writing to disk the last applied transaction log) can be seen at the bottom of the screenshot.If KT terminates unexpectedly in the middle of that loop, the timestamp file won’t be updated. When this KT restarts and if it successfully repairs the database it will replicate from the last value written to the rts file. KT could end up replaying days of transaction logs which were already applied to the DB and values written days ago could be made visible again to our services for some time before everything gets back up to date!We also regularly experienced databases getting out of sync without any reason. Sometimes these caught up by themselves, sometimes they didn’t. We have never been able to properly identify the root cause of that issue. Distributed systems are hard, and distributed databases are brutal. They require extensive observability tooling to deploy properly which didn’t exist for KT.Upgrading Kyoto Tycoon in ProductionMultiple processes cannot access one database file at the same time. A database file is locked by reader-writer lock while a process is connected to it.We release hundreds of software updates a day across our many engineering teams. However, we only very rarely deploy large-scale updates and upgrades to the underlying infrastructure which runs our code. This frequency has increased over time, but in 2015 we would do a “CDN Release” once per quarter.To perform a CDN Release we reroute traffic from specific servers and take the time to fully upgrade the software running on those machines all the way down to the kernel. As this was only done once per quarter, it could take several months for an upgrade to a service like KT to make it to every machine.Most Cloudflare services now implement a zero downtime upgrade mechanism where we can upgrade the service without dropping production traffic. With this we can release a new version of our web or DNS servers outside of a CDN release window, which allows our engineering teams to move much faster. Many of our services are now actually implemented with Cloudflare Workers which can be deployed even faster (using KT’s replacement!).Unfortunately this was not the case in 2015 when KT was being scaled. Problematically, KT does not allow multiple processes to concurrently access the same database file so starting a new process while the previous one was still running was impossible. One idea was that we could stop KT, hold all incoming requests and start a new one. Unfortunately stopping KT would usually take over 15 minutes with no guarantee regarding the DB status.Because stopping KT is very slow and only one KT process can access the DB, it was not possible to upgrade KT outside of a CDN release, locking us into that aging process.High-ish AvailabilityOne final quote from the KT documentation:Kyoto Tycoon supports "dual master" replication topology which realizes higher availability. It means that two servers replicate each other so that you don't have to restart the survivor when one of them crashed.[...]Note that updating both of the servers at the same time might cause inconsistency of their databases. That is, you should use one master as a "active master" and the other as a "standby master".Said in other words: When dual master is enabled all writes should always go to the same root node and a switch should be performed manually to promote the standby master when the root node dies.Unfortunately that violates our principles of high availability. With no capability for automatic zero-downtime failover it wasn’t possible to handle the failure of the KT top root node without some amount of configuration propagation delay.Building QuicksilverAddressing these issues in Kyoto Tycoon wasn’t deemed feasible. The project had no maintainer, the last official update being from April 2012, and was composed of a code base of 100k lines of C++. We looked at alternative open source systems at the time, none of which fit our use case well.Our KT implementation suffered from some fundamental limitations:No high availabilityWeak replication protocolExclusive write lockNot zero downtime upgrade friendlyIt was also unreliable, critical replication and database functionality would break quite often. At some point, keeping KT up in running at Cloudflare was consuming 48 hours of SRE time per week.We decided to build our own replicated key value store tailored for our needs and we called it Quicksilver. As of today Quicksilver powers an average of 2.5 trillion reads each day with an average latency in microseconds.Fun fact: the name Quicksilver was picked by John Graham-Cumming, Cloudflare’s CTO. The terrible secret that only very few members of the humankind know is that he originally named it “Velocireplicator”. It is a secret though. Don’t tell anyone. Thank you.Storage EngineOne major complication with our legacy system, KT, was the difficulty of bootstrapping new machines. Replication is a slow way to populate an empty database, it’s much more efficient to be able to instantiate a new machine from a snapshot containing most of the data, and then only use replication to keep it up to date. Unfortunately KT required nodes to be shut down before they could be snapshotted, making this challenging. One requirement for Quicksilver then was to use a storage engine which could provide running snapshots. Even further, as Quicksilver is performance critical, a snapshot must also not have a negative impact on other services that read from Quicksilver. With this requirement in mind we settled on a datastore library called LMDB after extensive analysis of different options.LMDB’s design makes taking consistent snapshots easy. LMDB is also optimized for low read latency rather than write throughput. This is important since we serve tens of millions of reads per second across thousands of machines, but only change values relatively infrequently. In fact, systems that switched from KT to Quicksilver saw drastically reduced read response times, especially on heavily loaded machines. For example, for our DNS service, the 99th percentile of reads dropped by two orders of magnitude!LMDB also allows multiple processes to concurrently access the same datastore. This is very useful for implementing zero downtime upgrades for Quicksilver: we can start the new version while still serving current requests with the old version. Many data stores implement an exclusive write lock which requires only a single user to write at a time, or even worse, restricts reads while a write is conducted. LMDB does not implement any such lock.LMDB is also append-only, meaning it only writes new data, it doesn’t overwrite existing data. Beyond that, nothing is ever written to disk in a state which could be considered corrupted. This makes it crash-proof, after any termination it can immediately be restarted without issue. This means it does not require any type of crash recovery tooling.Transaction LogsLMDB does a great job of allowing us to query Quicksilver from each of our edge servers, but it alone doesn’t give us a distributed database. We also needed to develop a way to distribute the changes made to customer configurations into the thousands of instances of LMDB we now have around the world. We quickly settled on a fan-out type distribution where nodes would query master-nodes, who would in turn query top-masters, for the latest updates.Unfortunately there is no such thing as a perfectly reliable network or system. It is easy for a network to become disconnected or a machine to go down just long enough to miss critical replication updates. Conversely though, when users make changes to their Cloudflare configuration it is critical that they propagate accurately whatever the condition of the network. To ensure this, we used one of the oldest tricks in the book and included a monotonically increasing sequence number in our Quicksilver protocol:… < 0023 SET “hello” “world” < 0024 SET “lorem” “ipsum” < 0025 DEL “42”… It is now easily possible to detect whether an update was lost, by comparing the sequence number and making sure it is exactly one higher than the last message we have seen. The astute reader will notice that this is simply a log. This process is pleasantly simple because our system does not need to support global writes, only reads. As writes are relatively infrequent and it is easy for us to elect a single data center to aggregate writes and ensure the monotonicity of our counter.One of the most common failure modes of a distributed system are configuration errors. An analysis of how things could go wrong led us to realize that we had missed a simple failure case: since we are running separate Quicksilver instances for different kinds of data, we could corrupt a database by misconfiguring it. For example, nothing would prevent the DNS database from being updated with changes for the Page Rules database. The solution was to add unique IDs for each database and to require these IDs when initiating the replication protocol.Through our experience with our legacy system, KT, we knew that replication does not always scale as easily as we would like. With KT it was common for us to saturate IO on our machines, slowing down reads as we tried to replay the replication log. To solve this with Quicksilver we decided to engineer a batch mode where many updates can be combined into a single write, allowing them all to be committed to disk at once. This significantly improved replication performance by reducing the number of disk writes we have to make. Today, we are batching all updates which occur in a 500ms window, and this has made highly-durable writes manageable.Where should we store the transaction logs? For design simplicity we decided to store these within a different bucket of our LMDB database. By doing this, we can commit the transaction log and the update to the database in one shot. Originally the log was kept in a separate file, but storing it with the database simplifies the code.Unfortunately this came at a cost: fragmentation. LMDB does not naturally fragment values, it needs to store every value in a sequential region of the disk. Eventually the disk begins to fill and the large regions which offer enough space to fit a particularly big value start to become hard to find. As our disks begin to fill up, it can take minutes for LMDB to find enough space to store a large value. Unfortunately we exacerbated this problem by storing the transaction log within the database. This fragmentation issue was not only causing high write latency, it was also making the databases grow very quickly. When the reasonably-sized free spaces between values start to become filled, less and less of the disk becomes usable. Eventually the only free space on disk is too small to store any of the actual values we can store. If all of this space were compacted into a single region, however, there would be plenty of space available.The compaction process requires rewriting an entire DB from scratch. This is something we do after bringing data centers offline and its benefits last for around 2 months, but it is far from a perfect solution. To do better we began fragmenting the transaction log into page-sized chunks in our code to improve the write performance. Eventually we will also split large values into chunks that are small enough for LMDB to happily manage, and we will handle assembling these chunks in our code into the actual values to be returned.We also implemented a key-value level CRC. The checksum is written when the transaction log is applied to the DB and checks the KV pair is read. This checksum makes it possible to quickly identify and alert on any bugs in the fragmentation code. Within the QS team we are usually against this kind of defensive measure, we prefer focusing on code quality instead of defending against the consequences of bugs, but database consistency is so critical to the company that even we couldn’t argue against playing defense.LMDB stability has been exceptional. It has been running in production for over three years. We have experienced only a single bug and zero data corruption. Considering we serve over 2.5 trillion read requests and 30 million write requests a day on over 90,000 database instances across thousands of servers, this is very impressive.OptimizationsTransaction logs are a critical part of our replication system, but each log entry ends up being significantly larger than the size of the values it represents. To prevent our disk space from being overwhelmed we use Snappy to compress entries. We also periodically garbage collect entries, only keeping the most recent required for replication.For safety purposes we also added an incremental hash within our transaction logs. The hash helps us to ensure that messages have not been lost or incorrectly ordered in the log.One other potential misconfiguration which scares us is the possibility of a Quicksilver node connecting to, and attempting to replicate from, itself. To prevent this we added a randomly generated process ID which is also exchanged in the handshake:type ClientHandshake struct { // Unique ID of the client. Verifies that client and master have distinct IDs. Defaults to a per-process unique ID. ID uuid.ID // ID of the database to connect to. Verifies that client and master have the same ID. Disabled by default. DBID uuid.ID // At which index to start replication. First log entry will have Index = LastIndex + 1. LastIndex logentry.Index // At which index to stop replication. StopIndex logentry.Index // Ignore LastIndex and retrieve only new log entries. NewestOnly bool // Called by Update when a new entry is applied to the db. Metrics func(*logentry.LogEntry) } Each Quicksilver instance has a list of primary servers and secondary servers. It will always try to replicate from a primary node which is often another QS node near it. There are a variety of reasons why this replication may not work, however. For example, if the target machine’s database is too old it will need a larger changeset than exists on the source machine. To handle this, our secondary masters store a significantly longer history to allow machines to be offline for a full week and still be correctly resynchronized on startup.UpgradesBuilding a system is often much easier than maintaining it. One challenge was being able to do weekly releases without stopping the service.Fortunately the LMDB datastore supports multiple process reading and writing to the DB file simultaneously. We use Systemd to listen on incoming connections, and immediately hand the sockets over to our Quicksilver instance. When it’s time to upgrade we start our new instance, and pass the listening socket over to the new instance seamlessly.We also control the clients used to query Quicksilver. By adding an automatic retry to requests we are able to ensure that momentary blips in availability don’t result in user-facing failures.After years of experience maintaining this system we came to a surprising conclusion: handing off sockets is really neat, but it might involve more complexity than is warranted. A Quicksilver restart happens in single-digit milliseconds, making it more acceptable than we would have thought to allow connections to momentarily fail without any downstream effects. We are currently evaluating the wisdom of simplifying the update system, as in our experience simplicity is often the best true proxy for reliability.ObservabilityIt’s easy to overlook monitoring when designing a new system. We have learned however that a system is only as good as our ability to both know how well it is working, and our ability to debug issues as they arise. Quicksilver is as mission-critical as anything possibly can be at Cloudflare, it is worth the effort to ensure we can keep it running.We use Prometheus for collecting our metrics and we use Grafana to monitor Quicksilver. Our SRE team uses a global dashboard, one dashboard for each datacenter, and one dashboard per server, to monitor its performance and availability. Our primary alerting is also driven by Prometheus and distributed using PagerDuty.We have learned that detecting availability is rather easy, if Quicksilver isn’t available countless alerts will fire in many systems throughout Cloudflare. Detecting replication lag is more tricky, as systems will appear to continue working until it is discovered that changes aren’t taking effect. We monitor our replication lag by writing a heartbeat at the top of the replication tree and computing the time difference on each server.ConclusionQuicksilver is, on one level, an infrastructure tool. Ideally no one, not even most of the engineers who work here at Cloudflare, should have to think twice about it. On another level, the ability to distribute configuration changes in seconds is one of our greatest strengths as a company. It makes using Cloudflare enjoyable and powerful for our users, and it becomes a key advantage for every product we build. This is the beauty and art of infrastructure: building something which is simple enough to make everything built on top of it more powerful, more predictable, and more reliable.We are planning on open sourcing Quicksilver in the near future and hope it serves you as well as it has served us. If you’re interested in working with us on this and other projects, please take a look at our jobs page and apply today.

How to Choose the Right Facebook Attribution Model

Social Media Examiner -

Are you struggling to track the impact of your Facebook ads? Wondering which Facebook attribution model to use? In this article, you’ll discover seven different Facebook ad attribution models to assess your campaigns’ performance. About Facebook Attribution Models The Facebook attribution tool gives you insights into your customers’ purchasing journey and the roles of different […] The post How to Choose the Right Facebook Attribution Model appeared first on Social Media Marketing | Social Media Examiner.

Dogfooding from Home: How Cloudflare Built our Cloud VPN Replacement

CloudFlare Blog -

It’s never been more crucial to help remote workforces stay fully operational — for the sake of countless individuals, businesses, and the economy at large. In light of this, Cloudflare recently launched a program that offers our Cloudflare for Teams suite for free to any company, of any size, through September 1. Some of these firms have been curious about how Cloudflare itself uses these tools.Here’s how Cloudflare’s next-generation VPN alternative, Cloudflare Access, came to be.Rewind to 2015. Back then, as with many other companies, all of Cloudflare’s internally-hosted applications were reached via a hardware-based VPN. When one of our on-call engineers received a notification (usually on their phone), they would fire up a clunky client on their laptop, connect to the VPN, and log on to Grafana.It felt a bit like solving a combination lock with a fire alarm blaring overhead. But for three of our engineers enough was enough. Why was a cloud network security company relying on clunky on-premise hardware? And thus, Cloudflare Access was born.A Culture of DogfoodingMany of the products Cloudflare builds are a direct result of the challenges our own team is looking to address, and Access is a perfect example. Development on Access originally began in 2015, when the project was known internally as EdgeAuth.Initially, just one application was put behind Access. Engineers who received a notification on their phones could tap a link and, after authenticating via their browser, they would immediately have access to the key details of the alert in Grafana. We liked it a lot — enough to get excited about what we were building.Access solved a variety of issues for our security team as well. Using our identity provider of choice, we were able to restrict access to internal applications at L7 using Access policies. This once onerous process of managing access control at the network layer with a VPN was replaced with a few clicks in the Cloudflare dashboard. After Grafana, our internal Atlassian suite including Jira and Wiki, and hundreds of other internal applications, the Access team began working to support non-HTTP based services. Support for git allowed Cloudflare’s developers to securely commit code from anywhere in the world in a fully audited fashion. This made Cloudflare’s security team very happy. Here’s a slightly modified example of a real authentication event that was generated while pushing code to our internal git repository.It didn’t take long for more and more of Cloudflare’s internal applications to make their way behind Access. As soon as people started working with the new authentication flow, they wanted it everywhere. Eventually our security team mandated that we move our apps behind Access, but for a long time it was totally organic: teams were eager to use it.Incidentally, this highlights a perk of utilizing Access: you can start by protecting and streamlining the authentication flows for your most popular internal tools — but there’s no need for a wholesale rip-and-replace. For organizations that are experiencing limits on their hardware-based VPNs, it can be an immediate salve that is up and running after just one setup call with a Cloudflare onboarding expert (you can schedule a time here). That said, there are some upsides to securing everything with Access.Supporting a Global TeamVPNs are notorious for bogging down Internet connections, and the one we were using was no exception. When connecting to internal applications, having all of our employees’ Internet connections pass through a standalone VPN was a serious performance bottleneck and single point of failure.Cloudflare Access is a much saner approach. Authentication occurs at our network edge, which extends to 200 cities in over 90 countries globally. Rather than having all of our employees route their network traffic through a single network appliance, employees connecting to internal apps are connecting to a data center just down the road instead.As we support a globally-distributed workforce, our security team is committed to protecting our internal applications with the most secure and usable authentication mechanisms.With Cloudflare Access we’re able to rely on the strong two-factor authentication mechanisms of our identity provider, which was much more difficult to do with our legacy VPN.On-Boarding and Off-Boarding with ConfidenceOne of the trickiest things for any company is ensuring everyone has access to the tools and data they need — but no more than that. That’s a challenge that becomes all the more difficult as a team scales. As employees and contractors leave, it is similarly essential to ensure that their permissions are swiftly revoked. Managing these access controls is a real challenge for IT organizations around the world — and it’s greatly exacerbated when each employee has multiple accounts strewn across different tools in different environments. Before using Access, our team had to put in a lot of time to make sure every box was checked.Now that Cloudflare’s internal applications are secured with Access, on- and offboarding is much smoother. Each new employee and contractor is quickly granted rights to the applications they need, and they can reach them via a launchpad that makes them readily accessible. When someone leaves the team, one configuration change gets applied to every application, so there isn’t any guesswork. Access is also a big win for network visibility. With a VPN, you get minimal insight into the activity of users on the network – you know their username and IP address. but that’s about it. If someone manages to get in, it’s difficult to retrace their steps.Cloudflare Access is based on a zero-trust model, which means that every packet is authenticated. It allows us to assign granular permissions via Access Groups to employees and contractors. And it gives our security team the ability to detect unusual activity across any of our applications, with extensive logging to support analysis. Put simply: it makes us more confident in the security of our internal applications.But It’s Not Just for UsWith the massive transition to a remote work model for many organizations, Cloudflare Access can make you more confident in the security of your internal applications — while also driving increased productivity in your remote employees. Whether you rely on Jira, Confluence, SAP or custom-built applications, it can secure those applications and it can be live in minutes.Cloudflare has made the decision to make Access completely free to all organizations, all around the world, through September 1. If you’d like to get started, follow our quick start guide here:Or, if you’d prefer to onboard with one of our specialists, schedule a 30 minute call at this link: calendly.com/cloudflare-for-teams/onboarding?month=2020-03

Migrating from VPN to Access

CloudFlare Blog -

With so many people at Cloudflare now working remotely, it's worth stepping back and looking at the systems we use to get work done and how we protect them. Over the years we've migrated from a traditional "put it behind the VPN!" company to a modern zero-trust architecture. Cloudflare hasn’t completed its journey yet, but we're pretty darn close. Our general strategy: protect every internal app we can with Access (our zero-trust access proxy), and simultaneously beef up our VPN’s security with Spectrum (a product allowing the proxying of arbitrary TCP and UDP traffic, protecting it from DDoS).Before Access, we had many services behind VPN (Cisco ASA running AnyConnect) to enforce strict authentication and authorization. But VPN always felt clunky: it's difficult to set up, maintain (securely), and scale on the server side. Each new employee we onboarded needed to learn how to configure their client. But migration takes time and involves many different teams. While we migrated services one by one, we focused on the high priority services first and worked our way down. Until the last service is moved to Access, we still maintain our VPN, keeping it protected with Spectrum.Some of our services didn't run over HTTP or other Access-supported protocols, and still required the use of the VPN: source control (git+ssh) was a particular sore spot. If any of our developers needed to commit code they'd have to fire up the VPN to do so. To help in our new-found goal to kill the pinata, we introduced support for SSH over Access, which allowed us to replace the VPN as a protection layer for our source control systems.Over the years, we've been whittling away at our services, one-by-one. We're nearly there, with only a few niche tools remaining behind the VPN and not behind Access. As of this year, we are no longer requiring new employees to set up VPN as part of their company onboarding! We can see this in our Access logs, with more users logging into more apps every month:During this transition period from VPN to Access, we've had to keep our VPN service up and running. As VPN is a key tool for people doing their work while remote, it's extremely important that this service is highly available and performant.Enter Spectrum: our DDoS protection and performance product for any TCP and UDP-based protocol. We put Spectrum in front of our VPN very early on and saw immediate improvement in our security posture and availability, all without any changes in end-user experience. With Spectrum sitting in front of our VPN, we now use the entire Cloudflare edge network to protect our VPN endpoints against DDoS and improve performance for VPN end-users.Setup was a breeze, with only minimal configuration needed:Cisco AnyConnect uses HTTPS (TCP) to authenticate, after which the actual data is tunneled using a DTLS encrypted UDP protocol. Although configuration and setup was a breeze, actually getting it to work was definitely not. Our early users quickly noted that although authenticating worked just fine, they couldn’t actually see any data flowing through the VPN. We quickly realized our arch nemesis, the MTU (maximum transmission unit) was to blame. As some of our readers might remember, we have historically always set a very small MTU size for IPv6. We did this because there might be IPv6 to IPv4 tunnels in between eyeballs and our edge. By setting it very low we prevented PTB (packet too big) packets from ever getting sent back to us, which causes problems due to our ECMP routing inside our data centers. But with a VPN, you always increase the packet size due to the VPN header. This means that the 1280 MTU that we had set would never be enough to run a UDP-based VPN. We ultimately settled on an MTU of 1420, which we still run today and allows us to protect our VPN entirely using Spectrum. Over the past few years this has served us well, knowing that our VPN infrastructure is safe and people will be able to continue to work remotely no matter what happens. All in all this has been a very interesting journey, whittling down one service at a time, getting closer and closer to the day we can officially retire our VPN. To us, Access represents the future, with Spectrum + VPN to tide us over and protect our services until they’ve migrated over. In the meantime, as of the start of 2020, new employees no longer get a VPN account by default!

Social Media Use Surges: How Marketers Should Respond

Social Media Examiner -

Welcome to this week’s edition of the Social Media Marketing Talk Show, a news show for marketers who want to stay on the leading edge of social media. On this week’s Social Media Marketing Talk Show, we explore what global spikes in social media usage mean for marketing strategies and LinkedIn’s new conversation ads format […] The post Social Media Use Surges: How Marketers Should Respond appeared first on Social Media Marketing | Social Media Examiner.

How To Maintain Business Continuity During COVID – 19

BigRock Blog -

COVID-19, or Coronavirus, is a global pandemic that has gripped the world. Personal and professional lives, mental and emotional stability; have all been affected and disrupted. It’s testing times like these that make the world come together as one, fight back and do everything in one’s power to continue as normally as possible.  The global economy has and will take a great hit. Businesses cannot run at a scale as they were before this — be it a large, medium, small, physical, or an online business.  While preparing ourselves for the after-effects is important, the need of the hour is to think of ways to continue during this pandemic.  The most important aspect to look into right now is self-care.  Taking care of your own health, proper sanitization, being aware of possible symptoms linked to Coronavirus, and ensuring that you neither spread nor contract the virus has to be the first thing each one of us enures.  If you’re a business owner, taking care of your employees is a close second priority. Just like yours, the health and safety of your employees is the key to keeping your business running. Regulating mandatory work from home, minimizing the number of staff that comes to work, medical and financial assistance — are some of the key factors that need to be thought-out and implemented.  Business Continuity: Plan, Strategize and Execute While you may not be able to run your business at a regular scale, you can certainly plan, and execute, strategies that allow you to continue doing business.  First, plan your way ahead. Then, strategize and analyze to understand the steps you’ll need to take to execute your plan. Finally, execute. Let’s take a closer look at each of these steps:  Step 1: Plan Just like any other business goal you set, business continuity must start with a proper plan in place. At this step, you need to understand what you need to achieve, and how you plan to achieve it.  If you’re an online business, what are the steps you need to take to continue providing your products and services?  If you’re an e-commerce store, how do you plan to deliver your products?  If you’re a physical business, how can you ensure safety and sanitization at your workplace? And, could you consider an online platform to continue the business, instead?  Analyze the needs of your business, your employees, your customers, and clients. Think of all the gaps and questions that may arise, and plan to offer solutions for the same.  Plan, plan, and plan some more before you move on to the next phase — Strategize.  Step 2: Strategize Once you’ve planned and chalked out all the questions you need to answer, it’s time to build a strategy that supports your business continuity plans.  By now, you should have a fair idea of the roadblocks, gaps, problems, and issues that may come in the way of you doing business. One-by-one, think of tools, people, or platforms that address these issues. Here are some things you need to start with:  Communicate with employees Set up a meeting (preferably online) to communicate the plan to your employees. Take suggestions, and offer solutions to tackle this as a team. Be a keen listener and understand the support your employees need to be able to carry on working efficiently. Be sensitive to their needs. If your business requires a certain number of employees to come into work, create a schedule considering everyone’s personal availability. Ensure the working space is sanitized, and has all the necessary measures in place to keep the working area safe for your employees. If you can run your business remotely, consider tools, gadgets or other essential support your team may need to continue working.  Multi-channel communication with customers  Once, as a team, you have strategized the best working plan, it’s time to touch base with your customers. It’s important that you reach out to them, letting them know that their best interests are your top priority. Using multi-channel communication, like email marketing, social media platforms, updated business listings, and others will allow you to reach out to all your customers. If there are any changes in your business plans or functioning, that directly affects your customers, now is the time to communicate to maintain credibility. Send marketing emails detailing the measures taken by your business and what it means for your customers, create social content to keep them regularly updated with your business and update your business work timings and contact information across business listings to ensure that your customers know how and when they can reach you.  Tweak delivery and pick-up options The global pandemic requires everyone to minimize human contact and maximize sanitization. If you’re a business that delivers physical goods to customers, you may need to think of the safest options to do so. You can collaborate with 3rd party delivery services, like Dunzo and WeFast in India, to continue the business. Additionally, there are many businesses, especially medical supplies and eateries, that have started self pick-up services. You can allow customers to call and place an order ahead of time, so they can just pick-up a clean parcel with limited or no human interaction from your physical store.  Set-up a basic online store  If you are a physical store, this may be a good time to consider setting up a basic online store. Buy a domain name, and a hosting package and set up a basic website for your store. You can slowly scale the products and services you offer online. As mentioned earlier, you can always tie up with 3rd party delivery services to fulfill online orders, and continue building revenue. Communicate to your customers about your online store through email and social platforms, letting them know that you are willing to go the length to continue serving them.  Step 3: Execute You’ve made a great plan, you’ve set up all the strategies you need to implement your plans — it’s execution time.  Put your strategies to execution and make changes, as and when required. You might discover new challenges along the way, but as long as you have a solid plan, you’ll be able to make the necessary changes to the strategies and carry on.  Move forward, keeping your team in the loop and with an open communication channel with your customers, and the execution will follow.  Take Charge; Stride Over COVID-19 has created an atmosphere of tension and despair across the globe. While the most important thing to do is practice self-care, one must also advocate best practices to keep employees safe, and businesses running.  This is the time to make the best use of technology, communication, and ethical work habits to stride over these difficult times. Every business needs to plan, strategize and execute measures that will ensure business continuity and minimize the effects of this global pandemic, on the global economy, as well as the existing needs of our customers.   

WordPress 5.4 RC5

WordPress.org News -

The fifth release candidate for WordPress 5.4 is live! WordPress 5.4 is currently scheduled to land on March 31 2020, and we need your help to get there—if you haven’t tried 5.4 yet, now is the time! You can test the WordPress 5.4 release candidate in two ways: Try the WordPress Beta Tester plugin (choose the “bleeding edge nightlies” option)Or download the release candidate here (zip). For details about what to expect in WordPress 5.4, please see the first release candidate post. Plugin and Theme Developers Please test your plugins and themes against WordPress 5.4 and update the Tested up to version in the readme to 5.4. The priority in testing is compatibility. If you find issues, please be sure to post to the support forums so we can figure them out before the final release. The WordPress 5.4 Field Guide is also out! It’s your source for details on all the major changes. How to Help Do you speak a language besides English? Help us translate WordPress into more than 100 languages! If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.

Tools of the Trade: Supporting your cPanel

cPanel Blog -

As a customer and partner, you have multiple ways to receive our help and support at any time, from anywhere. You have the power in your hands to obtain the knowledge and expertise necessary for your business to continue successfully without interruption. cPanel & WHM is a robust assortment of tools with a variety of applications for their use. These tools are widely used and adopted, and there are a lot of resources available. That means ...

Forget Slowing Down: It’s Time to Accelerate Your Digital Business

WP Engine -

As we all grapple with uncertainty and adapt to a changed marketplace, one thing remains clear: your business can’t afford to slow down.  Restaurants are moving quickly to establish online ordering and delivery services, gyms and yoga studios are racing to post online at-home workouts, and conferences and events that haven’t been canceled are going… The post Forget Slowing Down: It’s Time to Accelerate Your Digital Business appeared first on WP Engine.

Working Remotely Through the Internet

InMotion Hosting Blog -

Working remotely through the internet may include having to access a web-based application, updating or creating client websites, or simply interacting with your co-workers through web-based productivity suites or other applications. Many of us who are used to working in an office space may not be familiar with working away from the desktops that are anchored on an office desk.  What should you consider when working remotely? And are there any suggested solutions to go along with this list?  We will list a few concerns about working remotely and then suggest some solutions to go along with them.  This won’t be a comprehensive list, but at the very least it will include fundamental considerations for working remotely from the comfort of your home. Continue reading Working Remotely Through the Internet at InMotion Hosting Blog.

How to Improve Your Online Store Navigation for a Better Customer Experience

HostGator Blog -

The post How to Improve Your Online Store Navigation for a Better Customer Experience appeared first on HostGator Blog. Want more customers to buy from you? Help them find what they’re looking for fast. Today’s customers expect a frustration-free experience when they search for products in online stores. Sixty-five percent of them say finding stuff fast is their top priority when buying online. But many stores—even those with websites that cost millions to build—aren’t giving shoppers what they want.  The solution? Better site navigation and product search tools. Before you yawn, consider what the Baymard Institute learned when it tested user experience with the product listings and filtering functions on 19 eCommerce websites: “Despite testing multimillion-dollar sites, more than 700 usability issues related to product lists, filtering and sorting, arose during testing.” That’s an average of 37 ways to frustrate customers on each of the sites they tested. And when customers get frustrated, they leave. Baymard’s testing found that eCommerce sites with “mediocre product list usability” had abandonment rates ranging from 67% to 90%.  However, sites that were just a little bit better at helping customers find what they wanted had much lower abandonment rates, ranging from 17% to 33%. This is good news for smaller online stores, because clearly, a huge budget doesn’t guarantee a good product search experience.  What do you need instead? A good understanding of how customers look for products in online stores now is the place to start. Then you’ll know if you need to reorganize your product categories and add new tools to your site.  How Online Shoppers Search on eCommerce Sites Today Back in the olden days of the internet, product lists, menus and category tabs were the primary ways to find specific items. This was fine on a desktop, and there was a novelty factor to online shopping that made it kind of fun to see how categories and lists were set up.  Lists and categories are still useful, but a store that only offers those navigation tools is going to lose customers. What changed? Smartphones, for one. Mobile screen sizes required an alternative to scrolling through sidebar lists and product filters. The other big change is that eCommerce companies like Amazon poured resources into developing new ways to search in their store, and customer expectations for speed and convenience have been rising ever since. Shoppers now expect easy mobile site navigation. And some would rather use a search bar, voice search or a virtual shop assistant to find what they want. Here’s a quick example of how many ways customers can search a store now. Every element at the top of Amazon’s mobile homepage offers a different way to search, including a “hamburger” menu icon to browse categories.an Alexa icon to tell the virtual assistant to find what you’re looking for.a cart icon to see what’s already in your basket and what you’ve saved for later.a search bar that uses text or voice input and offers autocomplete suggestions, even if you misspell a word.a camera/code scanner icon for image and code searches.tabs for browsing popular categories. Not every online store can offer all these options. But remember, even small improvements can keep more customers on your site. Let’s explore ways you can make your product search and navigation better.  Categories, Menus, Product Lists and Filters for Your Online Store The product category tabs on your desktop site should guide your customers toward your most popular items as well as to your top-level product categories.  For example, Nordstrom’s category tabs include designer collections, sale items and brands even though those could be included as subcategories within the women, men and kids categories. But customers who like specific designers and brands, plus those who love deals, are more likely to shop if they can go right to the good stuff from the homepage. The same principle applies to your category menus.  See how new markdowns are the top menu item for Sales subcategories? Nordstrom wants frequent bargain hunters to be able to check out fresh items fast. If you have a lot of products, filters can help shoppers narrow their choices to a manageable number, although many customers now like to get relevant results faster in the search bar, which we’ll talk about below.  eCommerce platforms include basic navigation functions that let you set up categories and filters. But to help your customers find things faster, you may want to add layered navigation.  For example, WooCommerce’s Ajax-Enabled, Enhanced Layered Navigation extension gives you granular filter options like color swatches and size selections. Ajax Layered Navigation for Magento 2 lets you include an “add to wishlist” function on your menus. It also updates pages as shoppers apply filters without reloading the entire page, so customers can see their filtered results faster.  Search Bars on eCommerce Sites Your store needs to have a search bar, but not just any search bar. WordPress offers one for its sites, but there are more feature-rich options available for eCommerce platforms.  Why upgrade from the built-in search function? Because customers say relevant results are the most important part of a store’s on-site search, according to a survey by Digital Commerce 360 and Bizrate Insights. A search tool designed for your eCommerce platform can show customers what they’re looking for in ways a basic search can’t–and make them more likely to buy. Features to look for in an on-site search tool are:  Autocomplete suggestions.Rich search results with product suggestions and thumbnail images.Compensation for misspellings.AI-driven personalized search results.  Magento 2 users may want to try Fast Simon’s free Instant Search +, which also automatically generates product filter options based on search queries. For WooCommerce users, the Advanced Woo Search Plugin from Illid offers similar features. Its pro version can display stock status in search results and lets shoppers add items to their cart from search results. Chatbot Assistants for Product Search A chatbot “shop assistant” can help your customers find the exact product they need from your store, or it can offer them options. For example, if you’re looking for a blue T-shirt, a good chatbot assistant can show you several options with links to their product pages. It can learn to recognize customers and their shopping preferences for more personalized service with each visit. For WooCommerce users, the AcoBot AI Chatbot plugin for WordPress is an option worth trying. WP-Chatbot for Facebook Messenger is another option that works with multiple eCommerce platforms.  As you test out different options for improving your site navigation and search, remember to track your conversion and abandonment rates, and listen to customer feedback, so you can see which changes deliver the best results.  Want to learn more about improving customer experience in your store? Check out our 10-step guide to website usability testing. Find the post on the HostGator Blog

Using Cloudflare to secure your cardholder data environment

CloudFlare Blog -

As part of our ongoing compliance efforts Cloudflare’s PCI scope is periodically reviewed (including after any significant changes) to ensure all in-scope systems are operating in accordance with the PCI DSS. This review also allows us to periodically review each product we offer as a PCI validated service provider and identify where there might be opportunities to provide greater value to our customers.Building trust in our products is one critical component that allows Cloudflare’s mission of “Helping to build a better Internet” to succeed. We reaffirm our dedication to building trust in our products by obtaining industry standard security compliance certifications and complying with regulations.Cloudflare is a Level 1 Merchant, the highest level, and also provides services to organizations to help secure their cardholder data environment. Maintaining PCI DSS compliance is important for Cloudflare because (1) we must ensure that our transmission and processing of cardholder data is secure for our own customers, (2) that our customers know they can trust Cloudflare’s products to transmit cardholder data securely, and (3) that anyone who interacts with Cloudflare’s services know that their information is transmitted securely.The PCI standard applies to any company or organization that accepts credit cards, debit cards, or even prepaid cards for payment. The purpose of this compliance standard is to help protect financial institutions and customers from having their payment card information compromised. Each major payment card brand has merchants sorted into different tiers based on the number of transactions made per year, and each tier requires varying requirements to satisfy their compliance obligations. Annually, Cloudflare undergoes an assessment by a Qualified Security Assessor. This assessor conducts a thorough review of Cloudflare’s technical environment and validates that Cloudflare’s controls related to securing the transmission, processing, and storage of cardholder data meet the requirements in the PCI Data Security Standard (PCI DSS).Cloudflare has been PCI compliant since 2014 as both a merchant and as a service provider, but this year we have expanded our Service Provider scope to include more products that will help our customers become more secure and meet their own compliance obligations.How can Cloudflare Help You?In addition to our WAF, we are proud to announce that Cloudflare’s Content Delivery Network, Cloudflare Access, and the Cloudflare Time Service are also certified under our latest Attestation of Compliance!Our Attestation of Compliance is applicable for all Pro, Business, and Enterprise accounts. This designation can be used to simplify your PCI audits and remove the pressure on you to manage these services or appliances locally.If you use our WAF, enable the OWASP ruleset, and tune rules for your environment you will meet the need to protect web-facing applications and satisfy PCI requirement 6.6.As detailed by several recent blog posts, Cloudflare Access is changing the game and your relationship with your corporate VPN. Many organizations rely on VPNs and other segmentation tools to reduce the scope of their cardholder data environment. Cloudflare Access provides another means of segmentation by using Cloudflare’s global network as a VPN service to access internal resources. Additionally, these sessions can be configured to time out after 15 minutes of inactivity to help customers meet requirement 8.1.8!There are several large providers of time services that most organizations use. However, in 2019 Cloudflare announced our time.cloudflare.com NTP service. The benefits of using our time service rely on the use of our CDN and our global network to provide an advantage in latency and accuracy. Our 200 locations around the world all use anycast to route your packets to our closest server. All of our servers are synchronized with stratum 1 time service providers, and then offer NTP to the general public, similar to how other public NTP providers function. Accurate time services are critical to maintaining accurate audit logging and being able to respond to incidents. By changing your time source to time.cloudflare.com we can help you meet requirement 10.4.3.Finally, Cloudflare has given our customers the opportunity to configure higher levels of TLS. Currently, you can enable up to TLS 1.3 within your Cloudflare Dash, which exceeds the requirement to use the latest versions of TLS 1.1 or higher referenced in requirement 4.1!We use our own products to secure our cardholder data environment and hope that our customers will find these product additions as beneficial and easy to implement as we have.Learn more about Compliance at CloudflareCloudflare is committed to helping our customers earn their user’s trust by ensuring our products are secure. The Security team is committed to adhering to security compliance certifications and regulations that maintain the security, confidentiality, and availability of company and client information.In order to help our customers keep track of the latest certifications, Cloudflare continually updates our Compliance certification page - www.cloudflare.com/compliance. Today, you can view our status on all compliance certifications and download our SOC 3 report.

Creating Social Videos That Grow Strong Connections

Social Media Examiner -

Wondering how to use video to build stronger connections with your customers and prospects? Looking for a process to follow for your next video? To explore how to create emotional connections with video, I interview Matt Johnston on the Social Media Marketing Podcast. Matt is a former journalist turned video marketing expert and founder of […] The post Creating Social Videos That Grow Strong Connections appeared first on Social Media Marketing | Social Media Examiner.

Resources to Help You Navigate the Challenges of Today's Job Market

LinkedIn Official Blog -

The global economy has been shaken by the COVID-19 outbreak, leading to an increase in people applying for unemployment. As companies from a wide-range of industries experience a decline in hiring, people looking for a job are coping with uncertainty, assessing options, and fine-tuning their career search strategies in the face of a tough job market.  To help make this easier, we’re providing a free learning path of 12 courses to help you navigate these challenging economic times. Whether... .

Essential Website Elements that Increase Online Profits

InMotion Hosting Blog -

It’s no secret that your website is a great tool to generate more leads and profit for your business. However, bad web design and a cluttered layout can hurt your digital marketing efforts. In addition, omitting elements like a call to action (CTA) or a contact form can stunt your online growth and revenue. Why create a website if you’re not going to optimize it for business growth?  This article will guide you through essential website elements that increase online profits for small businesses. Continue reading Essential Website Elements that Increase Online Profits at InMotion Hosting Blog.

Pages

Recommended Content

Subscribe to Complete Hosting Guide aggregator