Below is a transcript from our Slack channel where we asked few question to Ryan Hickman about blockchain.Me : Can you tell about little bit history about crypto tech and where it lies in its current form ..and where it’s going?Ryan : That question is a rabbit hole, however when you begin to peel back the layers of the onion you begin to realize that the essence of crypto/blockchain tech is all about collaboration across a community with game theory at its core. i.e. without miners there is no bitcoin. without nodes there is no Ethereum, etc. there in lies the greatest strength.various people across the ecosystem finding ways to innovate on top of core ideas to forge new concepts that some find success where others may fail. you would be shocked if you read much of that score code from coin to coin to coin. The underlying technology is very much the same. the birth of bitcoin comes from the failure of the likes of b-money and others like bitgold. Adjustments in block sizes to remedy speed bring to life these forks like _lite coin_ and pure forks such as _bitcoin cash_ .Where some would challenge these ideals and suggest you could implement many of these use cases without blockchain — arguably true, there are killer cases that these technologies enable. As devs and other innovators continue to find ways to identify those cases surrounding markets are going to speculate towards the future supporting (game theory) such innovations in the form of market making.it’s funny because you can write an entire book on that subject. it’s very hard to summarise in short form.Me : Can you tell us what are current problems with the blockchain tech ?Ryan : Purely blockchain — tech speed, scale, fragmentation. Blockchain as cryptocurrency — liquidity, volatility and acceptance.Last year we developed a transnational protocol for artificial intelligence on Ethereum. When it was time to scale it, it was a disaster. We needed transaction speeds between machine to happen in ms, Ethereum was bottle necking in mins.Me : In terms of scalability and building blockchain on top of any platform like eos , eth or neo or others. which one is better, Ada is doing good and focusing on tech side very much?Ryan : Lisk/Ark are my preferred, Lightweight, nodejs based (more suitable for web application), dPos (delegated proof of stake) and fixed time intervals.Me: Can you tell us what kind of innovation you are seeing on blockchain tech ?Ryan: Identity has some of the coolest cases I’ve seen. They have some of the best chances. A.I. of course as that is near and dear to my heartMany of the projects are money grabs and simply don’t make sense to “blockchain-ifiy”.Me : Can you tell you what’s it will look like when A.I will meet blockchain ..what kind of problems it will solve?Ryan : The biggest problem it will solve is overcoming bias. (shameless plug → https://medium.com/craneai/building-unbiased-artificial-intelligence-inclusion-and-diversity-across-a-team-developing-a-i-bf4d7031234d )Me: how do you see miners in future blockchain industry?Ryan : You have to rethink miners. Hardware miners as we know it will become a thing of the past due to speed limits. The future in hardware mining will be distributed/pooled infrastructure such as GPU to train ML models or to process predictions. Miners will become people who provide votes, stake-based audits and contribute to the game theory mechanics in newer yet very applicable ways… bottom line, yes. They are critical we just need to elevate our thinking around what the term `miner` really means.Me: just more thing for our investor members, if you choose one Coin for future, which one it will be?Ryan: I don’t think the coin of the future has yet been developed.I’m a firm believer of `the code never lies` — which it does’t not. When blockchain tech can perform at the scale and speed of the existing protocols of the web, then I will hedge.We thanks Ryan to give us time and share his views. He is also our community member.Ryan Hickman is founder of Epic.AI, Passionately focused on building and investing in Artificial Intelligence and the Blockchain. His latest project is CoinDealer — The World’s Most Secure Way to Buy, Sell and Store Digital Currency. Web, iOS & Android App. Services: Buy Digital Currency, Secure Storage.If you are investor, Trader , developer or crypto enthusiast. Come join us on our slack community (Here). Our Crypto Forum CoinMonks and also check out our website which ranks crypto according to their development progress CoinCodeCap.❤️ Like, Share, Leave your commentIf you like this post, don’t forget to like, share with your friends and colleagues and leave your comment below about the post.And ………Follow Me to deep webPast, Present & Future of Blockchain: Interview with EpicAi Founder Ryan Hickman was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
SaaS Growth: No End in SightLast year, 2017, saw a slight slow-down in the pace of new SaaS subscriptions, but an increase in the amount being spent on SaaS. So while it may look like we are starting to see some consolidation around tools, it’s also true that organizations are not shy about shelling out for software as a service that will help them grow and manage their businesses.SaaS Trends: Why They MatterIt’s important to pay close attention to how software is being used in the modern business, because it’s the backbone of our economy today. Understanding SaaS trends can help businesses make good decisions about where to invest their own money. Additionally, digging deep on what’s working and what’s not can help uncover opportunities to improve.As we’ve written about before, SaaS security has a long way to go. Additionally, there are often major opportunities for cost savings when teams pay attention to where they are investing their dollars to avoid feature overlap and optimize resources. Productivity can either be dramatically improved or hampered by technology, depending on how workflows are structured, so periodically evaluating your SaaS usage (and taking a look at the wider industry) is a good way to understand whether you are moving in the right direction.Overall, it’s a good idea to pay attention to where SaaS momentum lies before you make any big decisions about where to invest, where to cut back, and how to better integrate and structure the technology your team already uses. Our hope is that this guide will help you do just that.SaaS Usage By Organizational DepartmentThe last ten years have resulted in a penetration of SaaS across all departments. While engineering was an unsurprising early frontrunner, and still a spending leader, Business Ops has taken the crown when it comes to number of subscriptions recent years. In 2018, it’s clear that SaaS is used widely across the entire organization.On average, we are seeing 18 SaaS subscriptions and about $136,000 in total spend at each company. However, it’s worth noting that as of Q3 2017, the run rate was closer to 20 subscriptions and $186,000 in annualized spending, so we expect these numbers to grow in 2018, just as they have in previous years.Let’s take a look at a departmental breakdown in SaaS usage and trends.💻 EngineeringEngineering teams are naturally powered by technology, and since they are of course the pioneers of SaaS, it makes sense that they were the first to jump in headlong. In 2009, engineering far outpaced other departments, with an average of 20 SaaS subscriptions per organization. Today, that growth continues unabated, with 2017 seeing about 1,108 subscriptions per org. Of course, there’s some overlap between engineering and DevOps, but here are the top three favorite products among pure-engineering teams:AWS: No one who works in the cloud will be surprised to find AWS at the top of this list, as the top cloud infrastructure provider out there.Google Cloud: Google Cloud hasn’t captured quite the market share that AWS has, but they are also a frontrunner in the cloud infrastructure game.New Relic: A “digital intelligence platform,” New Relic offers deep and wide insight into how your entire stack is performing, and has long been a favorite among devs.💼 Business OpsJust behind engineering, business ops stands out as a heavy user of SaaS products. In 2010, they already had an average of four subscriptions, and today that number has skyrocketed to 1370 per organization. It makes a lot of sense. Business ops pros are charged with keeping the whole organization humming along smoothly, and investing in tools that streamline, simplify, and facilitate communication is at the heart of what they do. Here are the top three business ops SaaS applications:GSuite: Not shocking to find the suite of apps that runs so many of today’s businesses here. GSuite is a favorite of ours for its ease of use, comprehensiveness, and security features.NetSuite: Need to manage your business’s financials, operations, and customer relations all in one place? NetSuite has your back.Slack: Perhaps the hottest communication tool on the market today, Slack is popular for its ability to replace email and bring teams into closer alignment. Plus, it’s fun to use.📣 MarketingMarketing has gone from an average of one SaaS subscription per organization to a whopping 647 today. As marketing becomes an increasingly technical and KPI-focused discipline, it’s no surprise that technology has been relied upon to support growth. This ranges from the big marketing automation platforms to a plethora of tailored solutions for everything from landing pages to design. Some of the top SaaS products for marketers include:Hubspot: No surprise this all-in-one marketing automation tool rises to the top, given it is able to scale up or down for everyone from SMBs to the enterprise.Marketo: Another marketing automation SaaS winner, Marketo is a popular tool among enterprises.Clearbit: Clearbit enables marketers to better understand their prospects, empowering the marketing department with data-driven insights.😀 Customer SupportIf your customers are tech-savvy, you certainly better be as well. It took a little while for customer support teams to start adopting SaaS, with 2012 seeing an average of just five apps per organization. They are still one of the lowest subscription rate departments, with just 168 on average in 2017, but it’s clear that the SaaS tools they are using are making a big difference. Customers today expect excellent support, and doing this at scale quite simply requires good technology. Some favorites for customer support include:Zendesk: A popular all-in-one customer service platform that offers everything from live chat to help desk to ticketing and more.Help Scout: Help desk software that aims to make customers service interactions more human (bonus points for being HIPAA compliant!)Front: A shared inbox for teams, Front makes it easier to interact with customers without dropping the ball along the way. empowering the marketing department with data-driven insights.💵 FinanceTime to get your financial house in order? In 2018, you’d be hard-pressed to do this successfully without the support of some excellent SaaS finance tools. While security and compliance concerns (and perhaps a bit of an old-school attitude) led to slow growth in this department — which averaged just one subscription as late as 2011 — it has clearly taken off in recent years. Today, the average finance department has 216 SaaS subscriptions under its belt. The best apps for their money?Recurly: As its name hints, Recurly offers a smart platform for companies who bill on a subscription basis.Zuora: Similar to Recurly, Zuora offers a subscription management platform that is well-liked by businesses who need to manage revenue closely.Bill.com: This service not only helps businesses get paid, but also helps them manage payments to vendors and contractors themselves.👩🏾💻 ProductBuilding a SaaS product? You’re gonna want some SaaS products to help you manage the process…In fact, even companies who aren’t building technology themselves can benefit from some of the powerful product development and management tools on the market today. Below are three popular SaaS tools for product teams:FullStory: Want to understand how your customers are interacting with your platform so you can improve the experience? FullStory’s the tool for you.Typeform: Most businesses need at least some forms on their websites, and Typeform offers a well-designed, streamlined way to build them.Zeplin: Need to shorten the path between design and development? Zeplin makes it easy to collaborate and ensure the final product looks exactly how it should.👨🏼🔧 DevOpsDevOps teams are natural early adopters, since they’re steeped in technology. Behind only engineering and business ops, they have grown from an average of two subscriptions per team in 2009 to 767 today. Since DevOps teams are tasked with both development and operations tasks, it makes sense that their SaaS investments span the gamut, with a focus on simplifying infrastructure to support continuous application delivery. Here are some stand-out SaaS tools that DevOps teams rely on:Heroku: This cloud platform enables companies to build, deliver, monitor and scale apps without worrying about infrastructure requirements.Joyent: Billing itself as “next-generation cloud,” Joyent offers computing, storage, and analytics for any type of infrastructure, including containers.Datadog: Monitoring and analytics for your entire technology stack, offering visibility and insights.💙 HRHuman resources teams have been the slowest to start adopting SaaS, with just two subscriptions on average per team as late as 2012. Today, it’s closer to 240. That growth comes from increasingly well-operationalized HR processes (like onboarding and offboarding) that require support in the form of technology to keep them running smoothly. Some big hits with HR professionals include:BambooHR: A powerful platform that includes everything from applicant tracking to self-onboarding to HR reporting.Gusto: HR, payroll, and benefits, all in one — plus access to HR experts on demand — makes this a popular choice for SMBs.Zenefits: This tool has something for everyone, from HR pros to customers to benefits brokers, offering a streamlined way to handle payroll, benefits, compliance, and more.🤝 SalesLast but not least, sales teams were a bit late to the game, with just four subscriptions on average in 2011. By last year, they were up to 331. That’s no surprise, given that sales teams are continually measured and KPI’d on how fast, efficiently, and effectively they are able to sell. There’s always room for improvement and an opportunity to trim the fat. Technology can be a huge enabler here. The three most popular SaaS tools for sales are:Salesforce: A lumbering SaaS giant, Salesforce offers pretty much anything a sales team could ask for, from opportunity tracking to proposals to analytics — and beyond.Outreach: This sales engagement platform helps teams fill the pipeline, book meetings, and find out which sales tactics actually work.InsightSquared: Time to show the board how things are going? InsightSquared turns data into clear, actionable revenue reports.With Great Power Comes Great ResponsibilityThe SaaS explosion is a good thing. It’s easier to deploy and faster to adopt, and it doesn’t require IT or developers to get started. Even less tech-savvy team members can deploy many SaaS products. People prefer it because apps can solve a wide range of business challenges. But when an organization invests in a lot of apps, it can lead to chaos pretty quickly.You have to consider how certain tools get along (or don’t) with other tools. You need to look for ways to streamline tech-heavy workflows. You need to ensure you are meeting security and compliance requirements and responsibilities, and treating customers’ data with the level of respect and sensitivity it deserves. You also need to ensure you are optimizing both operations and spending around SaaS tools, so that proliferation doesn’t equal waste.Investing in software as a service responsibly means addressing these challenges. That’s the only way to ensure your organization sees a net benefit from all that amazing technology.Blissfully: The Antidote to SaaS ChaosSound hard? Don’t worry. Blissfully helps hundreds of companies effortlessly manage their SaaS vendors, across thousands of subscriptions and millions in monthly spend. Once installed, Blissfully displays both historical and up-to-the-minute accurate representations of SaaS usage, spend, and data management.Blissfully offers:Automatic SaaS tool inventorying (including free and unsanctioned apps)Spend tracking and optimizationSecurity monitoring to reduce riskBuilt-in IT workflow streamlining and automationTry it free today.View more and download the full report freeYou can view the full report and download a PDF at blissfully.com/saas-trends/2018-annual/Originally published at www.blissfully.com.Blissfully 2018 Annual SMB SaaS Trends Report was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Default choices, irrational human beings and lessons for building products.The Nudge. Image courtesy: http://www.ellisjones.com.au/I’ve been reading a lot of behavioral economics books lately. I came across Richard Thaler’s book — ‘Nudge — Improving decisions about health, wealth and happiness’ when I was reading Daniel Kahneman’s Thinking Fast and Slow. Nudge was a natural progression from Kahneman’s book.The art of the Nudge is especially relevant to products managers who depend on soft influence to affect decisions. In a team/organization usually, different stakeholders can have different aims. For example the designer wants to optimize for users, the engineer wants to solve for elegance of the solution, the business person wants to optimize for revenue. Building consensus requires a lot of subtle nudges — whether it’s calling a meeting to discuss a design decision or an email listing down the minutes of a meeting or presenting user feedback to emphasize urgency of the problem to the engineer. Thus I was excited to read Thaler’s work.In the book Thaler discuss an idea called ‘libertarian paternalism’ — gently, non-coercively pushing people toward doing something that they really want to do. For example, a company might, by default, enroll new employees in a 401K plan and put a certain salary percentage into that plan. The employees can opt out or change their contribution amount at any time, but by enrolling everyone by default, the company does an end run around its workers’ natural procrastination tendencies, without forcing them into anything.The power of defaultsExperience shows that most users don’t bother to change the default settings — whether it’s your WhatsApp background or phone ringtone. Thus designing good default settings is crucial to improving the overall user experience.The iconic WhatsApp background:The iconic Whatsapp backgroundhttps://medium.com/media/d25242dfa569442b6221190cc67e138d/hrefAnother good example of power of default settings is a SIP — systematic investment plan. Surely we’ll be richer if we timed the market, studied stocks and invested in the right ones. However usually we’re too busy or too lazy to spend any meaningful time researching stocks. SIP ensures we’re diligently investing a % of our salary every month thus avoiding extra expenditure & ensuring a compounding return on our investments.Consider MakemyTrip which adds an insurance to your ticket by default.MakeMyTrip adds an insurance to your ticket by defaultHow does one choose the ‘right’ defaults?Does one optimize for the user or business?In some instances the choice is clear, the right choice for a user and business are one and the same — like the Google widget on the home screen. However it isn’t always so clear — consider autoplaying videos on Facebook.Autoplay on Facebook — why oh why?While auto-playing videos help increase video views for Facebook, it consumes precious data for the user. How does one choose between the two?Private products and companies are answerable to their users & the stock market. Free market competition ensures that companies strive to build products optimal for users. Thus if a default choice is detrimental to users it gets panned on the playstore forcing the developer to make changes. However in case of public policy, how does one ensure the default choice is in interest of the citizen?Thaler says that the individual should be nudged towards the more rational choice — something a rational human being or in his language 'econ' would choose. There are 2 variants of such a choice — 1. Helping an individual make a choice that is rationally better for himself 2. Nudging an individual towards a choice that is rationally better for the society but not necessarily for the individual. (Example everyone being an organ donor by default).Consider the example of retirement savings — contributing to your 401k or your PF account in the Indian context. While contributing more to your PF account might be more ‘rational’ choice in the long term, it reduces the amount of money available to people who might need it to send their school to children and to get food.The 2nd variant is more controversial. No framework is presented on when and how to make such a decision between 'good for the society' and 'good for the individual’ cases and how to inform the user about the choices being made. We see that in cases of public policy a nudge turns to a mandatory requirement — example Aadhaar.In conclusion, Richard Thaler makes an important point that we should pay keen attention to default choices as they have a big effect on our product experience/well being. Awareness about Thaler’s work helps us understand the innumerable default choices that the government and other products make for us and how it affects us. However we need to think about frameworks that ensure nudging is used in a constructive way, especially by governments.If you liked my article, please hit the clap button multiple times.At Comic Con, 2 years ago! Hello 👋References:https://www.forbes.com/sites/washingtonbytes/2017/10/21/when-the-nobel-prize-goes-pop-richard-thaler-and-the-uncertain-future-of-nudge/amp/ — echoes similar thoughts on the pros and cons of the Nudge approach.Nudge — the pros and cons of Noble prize winner Richard Thaler’s work was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Devs, stop complaining about recruiters. You sound like an asshole.Every so often, my Twitter stream — and probably yours — will include some annoyed or perversely-entertained developer sharing a tale of sorrow and woe. The tragedy? They’ve been spammed by a recruiter. Horror!Look.Are many technical recruiters clueless*?Sure.But aren’t you glad you have your job and not theirs?Then try gratefulness as a response instead of complaining/showboating to Twitter.Do you make over $60,000?Yes? Then you’re in the top 0.19% richest people in the world.No? Then respond to the recruiter!Either way, be grateful that while millions upon millions of people are looking for work (and in many parts of the world actual fucking water), an annoyance that registers on your radar is that from time to time someone sends you an email about a job.Tempted to justify your frustration by pointing out how blatantly irrelevant some recruiter spam can be? Reread that last paragraph.We are insanely lucky. We find ourselves in the midst of a thriving industry at a point in time when our skills are valuable and demand outweighs supply.That will not always be the case.When the tide turns and you find yourself knocking on doors, brushing up your resume, and sending personalized cover letters to position your background as remotely relevant in the brave new world, you’ll remember rolling your eyes at another email from yet another clueless recruiter and you may think, “What an asshole.”* I love @dhh. I read everything he writes, I watch every talk he posts, and I agree with almost all of it. I’m not exaggerating when I say that I would place him among my top 10 most influential authors. What I have never agreed with is how hard he is on recruiters.Yes, it’s comical that recruiters approach him for mid-level Rails positions considering that he, you know, invented it! But ridiculing an actual human being who wasn’t good at their job (when nobody was harmed) strikes me as borderline elitist with all the bad vibes.Originally published at http://brianrhea.com/stop-complaining-about-recruiters/Stop Complaining About Recruiters was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
- Tuesday, 13 February 2018 18:29
Yes! There is a kid around Yashu who is trying to mess up the interview. It's not a usual picture. But that should not deviate viewers from this latest episode of We Need to CryptoTalk, where Anuj Bairathi, founder & CEO of HashGains, speaks about India's growing cryptocurrency culture. In this tell-all conversation, Bairathi speaks about his upcoming cloud mining venture. Watch the full video. Subscribe to NewsBTC | Click Here ► https://goo.gl/JTkd7S Social Media Links:- Facebook - https://www.facebook.com/newsbtc/ G+ - https://plus.google.com/+NewsbtcBitcoin Twitter - https://twitter.com/newsbtc Telegram: http://t.me/newsbtcofficial Also, visit our website - https://www.newsbtc.com About Hashgains: HashGains is group company of 1500+ strong professionals and 2 mega data center’s parent Cyfuture with experience of over 15+ years in Data Center Industry serving 10 of 500 Fortune 500 Customers. Or interact with their team on their social media channels. Facebook: https://www.facebook.com/hashgains Twitter: https://twitter.com/hashgains LinkedIn: https://www.linkedin.com/company/hashgains YouTube: https://www.youtube.com/HashGains Instagram: https://www.instagram.com/hashgains/ Telegram: https://t.me/hashgains
- Tuesday, 13 February 2018 17:24
At this year’s World Economic Forum in Davos John Wise met up with Cointelegraph to talk about how an idea can not only be valuable but also profitable. John has a new take on economics and wants to see it grow into something more ethical and beneficial to everyone. Subscribe to our channel for even more videos! OUR CHANNEL https://www.youtube.com/user/cointelegraph ABOUT COINTELEGRAPH https://cointelegraph.com/ https://telegram.me/thecointelegraph https://www.facebook.com/cointelegraph https://twitter.com/cointelegraph https://soundcloud.com/cointelegraph/
Coincheck has met the FSA deadline, handing in a report on the $534 mln NEM hack last month. #ANALYSIS
In this series of posts, I will walk you through architecting, building and deploying a large scale, multi-region, active-active architecture, all while trying to break it. My initial idea is to split the series into the following structure:The Quest for Availability. (this post)Why and how do we build a Multi-Region, Active-Active Architecture?Building a Multi-Region, Active-Active Serverless Backend.Breaking things with Chaos Engineering.Of course, it might and probably will change as I start writing, so feel free to steer the course of (t)his (s)tory :)System Failure.One of my favourite quote, and also one that influenced my thinking of software engineering is one from Werner Vogels, CTO at Amazon.com.“Failures are a given and everything will eventually fail over time.”Indeed, we live in a chaotic world, where failure is a first-class citizen. Failure usually comes in three flavours; the early failures, the wear-out (or late) failure and the random failures, each coming at a different stage in the life of any given system.The “bathtub” curve of failure.Early failures are essentially related to programming and configuration bugs (typos, variable mutations, networking issues like ports and IP routing misconfiguration, security, etc…). Over time, as the product (or version) matures and as automation kicks-in, those failures tend to naturally diminish.Note: I just mentioned “automation kicks-in”! This really means that you have to be using automation to experience this natural declining behaviour of early failures. Doing things manually won’t allow for that luxury.Wear-out (or late) failures — you often read online that software systems, unlike physical components, are not subject to wear-out failures. Well, software is running on hardware, right? Even in the cloud, software is subject to hardware failure and therefore should be accounted for. But that’s not all, wear-out failures also and most often are, related to configuration drifts. Indeed, configuration drift accounts for the majority of reasons why disaster recovery and high availability systems fail.Random failures are basically, well, random. A squirrel eating your cables. A shark brushing its teeth on transatlantic cables. A drunk truck driver aiming at the data-centre. Zeus playing with lightings. Don’t be a fool, over time, you too will eventually fall victim to ridiculous unexpected failures.BUT— we live in a world where velocity is critical and by that, I mean being able to deliver software continuously. To give you an idea of velocity at scale, Amazon.com, in 2014, was doing approximately 50 million deployments a year, that’s roughly 1.6 deployments per seconds. Of course, not everyone needs to do that, but the velocity of software delivery, even at smaller scale does have a big impact on customer satisfaction and retention.So how does velocity impact our “bathtub” failure rate curve? Well, it now looks more like the mouth of a shark ready to eat you raw. And indeed, for each new deployment, new early failures will be thrown at you, hoping to take your system down.How it really looks like.As you can easily notice, this creates a tension between the pursuit of high availability and the speed of innovation. If you develop and ship new features slowly, you will have a better availability — but your customer will probably seek innovations from someone else. On the other hand, if you go fast and innovate constantly on behalf of your customers, you risk failures and downtime — which they will not like.To help you grasp what you are fighting against, I included the table of “The Infamous Nines” of availability. Let that table sink in for a minute.If you want to have 5-nines of availability, you can only afford 5 minutes of downtime a year!!“The Infamous Nines” of AvailabilityFew years ago, I experienced first-hand a complete system meltdown. It took our team few minutes just to realise what was happening, another few minutes to get our sh*t together and slow our heart-rate down and another couple hours to complete a full system restore.Lesson learned: If __any__ humans are involved in restoring your system, you can say bye-bye to the Infamous Nines.So how can you reconcile both availability and velocity for the greater good of your customers?There are three important things, namely:Architecting highly reliable and available systems.Tooling, automation and continuous delivery.Culture.Simply put, what you should aim for is having everyone in the team confident enough to push things into production without being scared of failure. And the best way to do so is by first having highly available and reliable systems, having the right tooling in place and by nurturing a culture where failure is accepted and cherished. In this following, I will focus more on the availability and reliability aspect of things.It is worth remembering, that generally speaking a reliable system has high availability but an available system may or may not be very reliable.Understanding Availability.Consider you have 2 components, X and Y, respectively with 99% and 99.99% availability. If you put those two components in series, the overall availability of the system will get worse.Availability in series.It is worth noting that the common wisdom “the chain is as strong as the weakest link” is wrong here — the chain is actually worsened.On the other hand, if you take the worse of these components, in that case, A with 99% availability, but put it in parallel, you increase your overall system availability dramatically. The beauty of math at work my friends!Availability in parallel.What is the take away from that?Component redundancy increases availability significantly!Note: you can also calculate availability with the following equation:Calculating System AvailabilityAlright, now that we understand that part, let’s take a look at how AWS Regions are designed.AWS Regions.From the AWS website, you can read the following:The AWS Cloud infrastructure is built around Regions and Availability Zones (“AZs”). A Region is a physical location in the world where we have multiple Availability Zones. Availability Zones consist of one or more discrete data centers, each with redundant power, networking and connectivity, housed in separate facilities.Since a picture is worth 48 words, an AWS Region looks something like that.An example AWS Region with 3 AZs.Now you probably understand why AWS is always, always talking and advising its customers to deploy their applications across multi-AZ, preferably three of them. Just because of this equation my friends.By deploying your application across multiple AZs, you magically increase, and with minimal effort, it’s availability.Application deployed across multi-AZ using a Elastic Load Balancer (ELB).This is also the reason why using AWS regional services like S3, DynamoDB, SQS, Kinesis, Lambda or ELBs just to name a few, is a good idea — they are by default, using multiple AZs under the hood. And this is also why using RDS configured in multi-AZ deployment is neat!The price of AvailabilityOne thing to remember though is that availability does have a cost associated with it. The more available your application needs to be, the more complexity is required and therefore the more expensive it becomes.The price of Availability.Indeed, highly available applications have stringent requirements for development, test and validation. But especially, they must be reliable, and by that, I mean fully automated and supporting self-healing, which is the capability for a system to auto-magically recover from failure. They must dynamically acquire computing resources to meet demand but they also should be able to mitigate disruptions such as misconfigurations or transient network issues. Finally, it also requires that all aspects of this automation and self-healing capability be developed, tested and validated to the same highest standards as the application itself. This takes time, money and the right people, thus it costs more.Taking it up a notchWhile there are tens, or even hundreds of techniques used to increase application reliability and availability, I want to mention two that in my opinion stand-out.Exponential backoffTypical components in a software system include multiple (service) servers, load balancers, databases, DNS servers, etc. In operation, and subject to potential failures as discussed earlier, any of these can start generating errors. The default technique for dealing with these errors is to implement retries on the requester side. This simple technique increases the reliability of the application and reduces operational costs for the developer.However, at scale and if requesters attempt to retry the failed operation as soon as an error occurs, the network can quickly become saturated with new and retired requests, each competing for network bandwidth — and the pattern would continue forever until a full system meltdown would occur.To avoid such scenarios, exponential backoff algorithms must be used. Exponential backoff algorithms gradually increase the rate at which retries are performed, thus avoiding network congestion scenarios.In its most simple form, a pseudo exponential backoff algorithm looks like that:Simple exponential backoff algorithmNote: If you use concurrent clients, you can add jitter to the wait function to help your requests succeed faster. See here.Luckily many SDKs and software libraries, including the AWS ones, implement a version (often more sophisticated) of this algorithms. However don’t assume it, always verify and test for it.QueuesAnother important pattern to increase your application’s reliability is using queues in what is often called message-passing architecture.The queue sits between the API and the workers, allowing for the decoupling of components.Message-passing pattern with queues.Queues give the ability for clients to fire-and-forget requests, letting the task, now in the queue, to be handled when the right time comes by the workers. This asynchronous pattern is incredibly powerful at increasing the reliability of complex distributed applications but is unfortunately not as straightforward to put in place as the exponential backoff algorithms since it requires re-designing the client side. Indeed, requests do not return the result anymore, but a JobID, which can be used to retrieve the result when it is ready.Cherry on the cakeCombining message-passing patterns with exponential backoff will take you a long way in your journey to minimise the effect of failures on your availability and are in the top 10 of most important things I have learned to architect for.That’s is for this part. I hope you have enjoyed it. Please do not hesitate to give feedback, share your own opinion or simply clap your hands. The next part will hopefully be published next week. Stay tuned!-AdrianThe Quest for Availability. was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.