DEV Community: Alex Boykov

How do I implement liveness detection in Python to prevent fraud

Alex Boykov — Wed, 01 Mar 2023 22:58:53 +0000

Introduction

In today's digital world, fraud prevention is a top priority for businesses. One of the ways to prevent fraud is to use liveness detection technology, which can determine if a person is a real human or a computer-generated image.

In this article, I will show you how to implement liveness detection API in Python to prevent fraud in less than 5 minutes.

Sign up for an API key

First, you need to sign up for an API key from a liveness detection service provider. After signing up, you will receive an API key, which you will use to access the liveness detection API.

Install required libraries

To use Luxand.cloud API, you need to install the Requests library in Python. You can install it using pip, by running the command: "pip install requests"

Call Liveness Detection API

To call the liveness detection API, you need to send a POST request to the API endpoint with the user's photo. The API will analyze the photo and return a response indicating whether the user is alive or not.

Here is a sample Python code to call the Liveness Detection API:

import requests
import json

url = "https://api.luxand.cloud/photo/liveness"

headers = {
    "token": "<YOUR_API_KEY>"
}

files = {
    "photo": open("<PATH_TO_YOUR_PHOTO>", "rb")
}

response = requests.post(url, headers=headers, files=files)

if response.ok:
    result = json.loads(response.content)
    if result['result'] == "real":
        print("User is alive.")
    else:
        print("User is not alive.")
else:
    print("Error occurred while calling API.")

Use the Response

Once you receive the response from the API, you can use it to authenticate the user. If the user is alive, you can proceed with the authentication process. If the user is not alive, you can reject the request and prevent fraud.

Conclusion

In just 5 minutes, you have successfully implemented liveness detection in Python using Luxand.cloud API. With this simple addition to your authentication process, you can prevent fraud and protect your application from spoofing attacks.

This guide is just the beginning, and we encourage you to explore further and find other ways to leverage the power of Luxand.cloud API.

The best way to promote your NFT collection

Alex Boykov — Tue, 07 Jun 2022 08:13:21 +0000

Web3-projects are gaining popularity at a rapid pace. One of the most popular Web3 technologies is NFT or non-fungible token. It is a digital asset consisting of data stored in a blockchain. The ownership of an NFT is recorded in the blockchain, and can be transferred by the owner, allowing NFTs to be sold and traded. Creators make several NFTs united by one theme, and such a set of NFTs is a collection. Every day new NFT collections and tools for creators and holders are launched - all of them need to somehow tell the world about themselves before their mint (sale) date. At this point, the need for collaboration appears.

Collabs are essential throughout the project life cycle, especially at the pre-sale stage. Post-mint collabs (after mint date) have the goal of adding value for the holders of both projects, e.g. by sharing pieces of technology and not necessarily promoting them to new people.

Pre-sale collaborations are made between two projects to expand their communities, raise interest in a new collection and collect access lists of collectors willing to buy. There are two main ways to organize pre-sale collaboration, let’s shed some light on each of them.

Classic collaboration
Whitelist marketplaces

Classic collaborations are made between two collections, organized by one collection (usually the new one) and made on the Discord or Twitter channel of another collection (usually a more popular one).

In such collaborations you usually get the opportunity to win WL spots by completing several conditions (joining a Discord channel, leaving a reaction to the post, etc.). The winners are determined randomly using bots - for example, Giveaway bot in Discord or Twitter Picker on Twitter).

Collaborations are more often held in Discord, and less often on Twitter. On Discord it’s usually 50-100 WL spots in giveaways and 5-10 WL spots on Twitter. The reason for this is the audience you can reach. On Discord you only cooperate with reliable servers, so the audience is more involved, they have relevant experience and tokens in their collections. However, this audience is limited to the members of the servers. On Twitter the audience is much wider (it’s only limited by the number of Twitter users), you can share tweets and get more and more reach, but these people are less engaged.

How to measure the success of your collaboration? The more people are reached and the more sign-ups you get for your WL and new members in your community, the more effective the collaboration. Perfect collaboration occurs when holders of the collection you’re collaborating with have tokens of more popular collections. Then you know that you have a good chance of being exposed to the blue-chip holders.

Whitelist Marketplaces - is an alternative way of collaborating where there are no randomly held giveaways, collectors receive their WL sport guaranteed for some amount of the native token of the marketplace host project. Say, for example, you have some $SPIT, a Llamaverse token. You can enter their marketplace (provided you hold a Llamaverse Genesis NFT for the access), find a collection you are interested in and buy their WL in exchange for $SPIT.

In projects that host WL marketplaces holders usually get incentivized to stake the NFT they have which leads to a decrease in NFT listings and an increase in price. That’s why it’s good for collections to have marketplaces so they can get new projects there.

Here are some examples of Whitelist Marketplaces:

isoroom store

llamaverse Marketplace

$SATOSHI Marketplace

Reconrams-adventure Marketplace

THE HABIBIZ Marketplace

Chillbear.club Marketplace

How to organize collabs?

Basically, all you need to do to make a collaboration is to establish a connection with founders or collab managers. Sometimes popular projects even have a collab request form to fill in. If your project is new and unknown, it will be pretty hard to make a collaboration with some blue-chip collection. Moreover, it’s very time-consuming to send dozens if not hundreds of collab requests. It is better to hire a collaboration manager so as not to spend days on it. You'll gain better results from collaborations.

A collab manager is a person responsible for establishing these kinds of connections in a web3 space. The main responsibility is to organize collaboration - find the best collections, negotiate with their founders, and make sure that all winners are taken care of at the time of mint.

So it’s public relations plus some down-to-earth work, which means that a perfect collab manager should be well-known among holders and at the same time responsible and organized.

Usually, in order to get WL in such collaborations collectors need to fulfill some conditions: join the Discord channel, follow the project’s Twitter account and sometimes invite other people. The fulfillment of the conditions of collaboration has to be controlled by someone. These activities usually also fall under the purview of a collab manager. And you can often find yourself with dozens of collaborations going on at the same time and thousands of collectors participating - managers have to control all of it. When it gets hard to manage so much data it’s better to use WL building services to create a collaboration. Such services will automatically check all the requirements, collect analytics and keep track of all participants. A lot of manual work can be avoided. All you need to do is create your collaboration page and spread a link on it in your and your partner’s Discord.

Here are some of these tools:

Letsmint.io

Premint.xyz

Podiumnft.com

Where to find a collab manager?

Even if you use tools to automate most of the process, you still need people to negotiate collaborations. These people are collab managers. So how to hire such people? Just like in any other sphere, collab managers are not equally effective. There are a lot of cheap workers out there. These specialists are good at the most mundane work - sending hundreds of collab requests to all the projects they are able to find and then making sure winners got their WL. Cheap managers aren’t well-connected in the web3 space, so don’t expect to make a collaboration with overly hyped projects. Moreover, they may not be very responsible and may just not see through all the deals or simply disappear midway. Hire them if you need to do a preliminary market research, test the water or reach as many collections as possible.

If you want to have the best collab manager and you are ready to spend some money on it, look for popular or successful products you like. Successful collections usually have a well-connected collab manager, so this person may help you to open many doors.

Such a person can also assess the potential of the project and choose the best way to market it. Don’t hesitate to contact the person you’re interested in - when the project has already passed the stage of active marketing, the collab manager will usually be able to take one more project to work on.

If you are not ready to pay for the best one, you can look for the best fit on NFT jobs websites.

Here’s a shortlist of them (some require ownership of their token):

Collaborations are crucial for marketing collections and tools. NFT space is oversaturated with projects, so it is much easier to get known in the market by relying on well-known, famous names. So the quality of your collaborations is more important than the quantity. Find good collab managers, target famous collections for collaboration, and very best of luck!

3 steps to test faster and easier

Alex Boykov — Fri, 23 Jul 2021 11:57:20 +0000

A friend of mine once told me, “Development can be defined as a painfully long process, yielding a product that’s different from what was requested, packed with bugs and defects, which takes three times longer to develop at a higher cost.”

To that, most developers will reply, “C'est la vie”, because cynical as it may sound, that definition is pretty accurate.

That’s not to say that developers are incompetent; quite the opposite. But unfortunately, the process of development is flawed. There are too many stakeholders involved — developers, designers, product managers, CEOs and so on — and all of them have their own requirements for what should be included in the final product.

So, product managers create specifications, designers produce designs, developers assemble the code and deliver it to the testers. Of course, the testers find bugs and send the code back to the developers. And on and on we go in an endless, infernal cycle!

The single point of failure is the testing stage.

Testers usually run their tests inside special environments, such as sandbox versions of the product being tested.

Due to the nature of the process, a lot of time passes from the moment when developers create the first pull requests, to the moment when those changes are ready for another test.

Moreover, designers, product managers and other stakeholders are not involved in the testing process; they only see the released version. And by that time, the product might have veered way off course, resulting in something that doesn’t match the initial requirements.

That’s how it has always been.

But what if we could review pull requests in a live setting? How much time, energy and frustration would it save the entire team?

That’s exactly what we did at Hostman.

Like everyone else, we were exhausted by the infinite development/testing loop from hell. So we decided to do something about it.

Our solution — pull request previews.

Pull request previews allow us to review every PR not only in code format (as it used to be), but also in a live setting. As soon as our dev team creates a new pull request, the whole team is able to review the changes — individually, at their own workstations.

Here’s how it works:

We have our website hosted on Hostman.
Hostman is connected to our GitHub repository (also works with Gitlab, Bitbucker and other popular services).
Everytime someone from the dev team makes a PR, Hostman automatically builds our project to a temporary domain.

We get a temporary link that can be shared internally with the project’s stakeholders, so that they may review the build and offer feedback. This link replicates all of the settings of the live website, including free SSL. So, the team sees a replica of the live website, but with the implemented changes.
We can review the design, test new features, and make sure that the build is still on track with the briefing.
We leave comments and send all our edits to the developers, so they can course-adjust accordingly.
Once this process is completed, the temporary link self-destructs automatically.

This process has shortened our developing cycle dramatically. A team-wide review of the changes now takes roughly an hour, as opposed to multiple days. And we can even conduct several tests per day. Developers make changes → they create a PR → the team reviews → the developers adjust → the team reviews again → the product ships! It happens so fast, that team enthusiasm and momentum remain at a high. More importantly, the feature being developed doesn’t lose its relevance, as sometimes happens with lengthy testing times 😀.

The initial website

Pull request preview

But that’s not all. PR previews have drastically improved our team dynamic. Having the whole team actively involved in the development process from the very beginning, is incredibly motivating for everyone. Rather than having to patiently wait for the black box to open and see the result, everyone in the team can offer their contribution at every stage. And in the end, we all get that sense of fulfillment of having created something new together.

Pull request previews will completely redefine your creative process as a team! And we’re not just saying this because we made them, but because they were born out of a strong pain we’ve experienced as a team.

We’ve tried them in our own creative process, we’ve put them through the paces, tested them extensively and even tried to break them. But they have consistently made our work more efficient and our team more productive.

So if you’re stuck in development cycle hell, give PR previews a try. In Hostman you can create up to 3 websites for free, and create PR previews right away.

Try them out now and we promise you’ll never look back.

How we saved hours on testing and started shipping projects faster

Alex Boykov — Tue, 20 Jul 2021 14:09:03 +0000

To that, most developers will reply, “C'est la vie”, because cynical as it may sound, that definition is pretty accurate.

The single point of failure is the testing stage.

Testers usually run their tests inside special environments, such as sandbox versions of the product being tested.

Due to the nature of the process, a lot of time passes from the moment when developers create the first pull requests, to the moment when those changes are ready for another test.

That’s how it has always been.

But what if we could review pull requests in a live setting? How much time, energy and frustration would it save the entire team?

That’s exactly what we did at Hostman.

Like everyone else, we were exhausted by the infinite development/testing loop from hell. So we decided to do something about it.

Our solution — pull request previews.

Here’s how it works:

We have our website hosted on Hostman.
Hostman is connected to our GitHub repository (also works with Gitlab, Bitbucker and other popular services).
Everytime someone from the dev team makes a PR, Hostman automatically builds our project to a temporary domain.

The initial website

Pull request preview

So if you’re stuck in development cycle hell, give PR previews a try. In Hostman you can create up to 3 websites for free, and create PR previews right away.

Try them out now and we promise you’ll never look back.

How to choose the best application hosting provider

Alex Boykov — Thu, 11 Mar 2021 14:44:16 +0000

Application hosting is gaining popularity among both startups and corporations looking to save time and money. Cloud providers automate all the hard work: installing dependencies, setting up networking, SSL, load balancers, etc. Previously this would have required a whole DevOps team and considerable time. Today, modern solutions allow you to connect your repository, deploy it, and watch your app go live in just a few minutes.

The biggest challenge is choosing the right application hosting provider—one that’s perfect for your company or product in terms of price, functionality, and security. In this article we’ll be looking at two cloud providers: the well-known Heroku and the promising startup Hostman. We’ll compare both and assess the main pros and cons of each.

Heroku is a platform owned by Salesforce. It is a fully-managed platform that, according to their website, provides the simplest path to delivering apps quickly. It is based on a managed container system with integrated data services, and has over 100 built-in add-ons for monitoring, caching, networking, etc.

Hostman is a cloud platform that deploys and scales web apps and websites. It too is a container oriented system, with each instance launched inside its own Docker container.

Reliability and performance

Heroku runs on AWS and has proven to be stable, so you won’t have to deal with the occasional service outage. What you will have to deal with is your dynos (containers that run Heroku apps) going to sleep after every 30 minutes of inactivity. This can be a pain, but it only happens with free dynos. Another issue is that Heroku applications restart every 24 hours to maintain app health, so you’ll lose chases and other in-memory states, as well as your websocket connection.

Hostman runs on top of AWS and DigitalOcean, so your stability is assured. Hostman applications and services never fall asleep or become inactive, and Hostman also has zero downtime deploys. That way, even if something happens to your build, your app won’t go down.

Ease of use

Heroku automates much of the server setup and provisioning, allowing you to have your app live in a matter of minutes. Some might say that deploying with Heroku is easy. And it is, compared to AWS or Azure. The thing is, Heroku is one of the oldest cloud providers, and while this means they have lots of experience, they’ve also become unwieldy and can seem fairly complicated to beginners, as many things still have to be managed manually. But one of the things people like about Heroku is its CLI that allows you to manage your Heroku apps directly from the terminal.

Hostman is designed to be super easy. Every step is intuitive, so you won’t run into any problems—even if you’re deploying your app for the first time. You don't even have to write config files. After deployment, Hostman automatically sets up an SSL certificate for all your domains and puts a CDN in place to deliver your content as fast as possible. There’s no CLI in Hostman, but apparently you don’t need one, because everything you do in GitHub is automatically updated in Hostman. Another plus is Hostman’s ability to launch Docker images from a Docker repository, or to build a custom image using a Dockerfile. All this allows you to deploy your app very fast, and also to easily edit, scale, and monitor.

Pricing

To be honest, Heroku’s pricing tiers are rather complicated. It’s like a puzzle: you have to put the pieces together to see the final price. Basically, Heroku’s pricing depends on the number of dynos you need, and starts at $7/mo. There is a free tier, but it won’t be of much use for serious projects: it includes a single dyno instance, 512MB of memory, two process types, and your app will go to sleep after every 30 minutes of inactivity. The cost increases rapidly as you leave the free tier or scale your app vertically and horizontally with more dynos. In our experience, most applications require more than one dyno to run properly.

Hostman’s prices depend on the amount of RAM, SSD capacity, and CPU speed. On the website you can easily estimate the price you’ll pay, as tiers are conveniently determined by your app type. For frontend developers, Hostman lets you deploy 3 websites for free, while for backend developers they offer a 30-day trial. Regular price for apps or websites starts at $6/mo.

Conclusion

Heroku is a platform that has been helping developers for a long time, and enjoys well-earned credibility and popularity. But technology is constantly advancing, and developers are increasingly looking for Heroku alternatives. Heroku has a number of downsides, such as no native support for static websites, “sleeping” dynos, app restarts, and, of course, pricing.

Hostman is the new kid on the block, but is already gaining a following. Backed by the stability of AWS and DigitalOcean, Hostman supports the latest features, offers great scalability, and has straightforward pricing.

Comparison table

3 easiest ways to use facial recognition in your apps

Alex Boykov — Tue, 15 Dec 2020 15:16:16 +0000

In 2020, facial recognition became one of the most talked about technologies due to its wide adoption and highly controversial use by the Chinese government. However, the use of facial recognition technologies is not limited to government surveillance. Proprietary implementations of facial recognition are built into many modern smartphones and Windows laptops to facilitate seamless biometric identification and authentication of the user. Facial recognition is commonly used in the entertainment and fashion industries, security and surveillance applications.

When it comes to facial recognition libraries, the number of available options wide. You have the choice of using one of the open-source libraries of taking the proprietary route and licensing a face recognition SDK from a specialized company. In the end, you may be able to build an app using either platform, yet the path and the end result may differ significantly. So let’s discuss the available options and see their pros and contras.

The open source libraries

There are several open source facial recognition project around, such as OpenBR, Flandmark, OpenFaceTracker, Face-api.js. However, the most popular projects are OpenCV and dlib.

These two projects solve similar yet different tasks. While OpenCV mostly offers image processing with some machine learning available if you build from the source, Dlib is a designated AI-based machine learning library. Since these are different libraries solving different tasks, your project may need either one or both of them.

Each of these projects has a community backing the development. When it comes purely to facial recognition, both libraries do their job, yet neither is perfect. You can read a comprehensive comparison of the various facial recognition methods used in OpenCV and Dlip in Face Detection - OpenCV, Dlib and Deep Learning | Learn OpenCV. Without much ado, here’s the brief summary.

Pros:

Lightweight
Ready to go
Free and open source
Extensive communities and forum support

Cons:

Accuracy suffers in all modes
Difficult to strike the right balance between acceptable false negative and false positive rates
Backend architecture design and development required
Some features only work on frontal images
Ongoing issues recognizing images of visible minorities

Facial recognition SDK

If you decide to follow the proprietary route, you’ll have several options from the two major categories: offline facial recognition SDKs and online APIs. Let’s start with the former.

Commercial facial recognition SDKs are distributed as sets of libraries for various platforms and in various programming languages. The most common SDK’s handle the entire recognition process locally. Nothing is being transmitted over the network, and the recognition makes use of the local computer’s resources for doing its work. While this is can be a significant benefit in some applications, you have to consider the costs of designing, implementing and securing the backend infrastructure, which includes a database. An example of facial recognition SDK is Luxand FaceSDK.

Pros:

Works almost real-time on a local CPU
Easier to implement compared to open source libraries
Highly accurate recognition
Unlike online API’s, can be used inside DMZ
Good choice for high-power computers

Cons:

High upfront costs (must purchase a license before starting development)
Licensing costs (sometimes recurrent)
More difficult to implement compared to online API’s
Infrastructure design and implementation required (including database architecture)
Depending on the SDK, limited support for different programming languages

Facial recognition API

Some SDKs expose high-level APIs implementing common tasks associated with face recognition on a remote server.

The main advantage of facial recognition APIs is the ease of implementing them in your product. The backend infrastructure has been already taken care for by the API provider, so your app or Web service only needs to make a few calls to get things done. Since the APIs are making calls to a remote server instead of including complex biometric models and machine learning stuff, the implementation is extremely lightweight. Authenticating, registering a face and submitting a face for recognition/identification are implemented with several high-level calls.

Facial recognition APIs have their share of drawbacks, the most important is the fact that you need an Internet connection for it to work; this, however, has very little importance for Web apps and apps having access to the Internet.

Pros:

Zero upfront costs
Extremely lightweight
The easiest way to start with
Complex operation implemented via single high-level API call
Everything is ready
Infrastructure development not required (the database is already in the cloud)
All programming languages supported
Good choice for web applications and thin clients
Good choice for mobile apps

Cons:

Recurring costs or licensed per usage
Online only, Internet connection always required
Higher latency due to online overhead

Conclusion

The choice of a free open-source SDK, a commercial version of the same, and an online facial recognition API depends on the intended application, available time and resources.

Open Source libraries are free of charge, yet require the most effort to implement. Commercial SDKs can be easier to implement and deliver more convincing results in the end, yet you still have to design and implement the backend on your own.

The online APIs by and large are the easiest to use, requiring no upfront fees and only charging for services that you actually use. In my view, online APIs are great for connected mobile apps and Web apps that aren’t time critical, with expected small to medium usage. For my apps, I prefer Luxand.cloud API for its fast implementation, precisely tuned recognition and ease of use.

What’s the difference between CI and CD?

Alex Boykov — Fri, 04 Dec 2020 11:48:23 +0000

Despite the common trend for automation of development processes, there are still some companies where testing and deployment aren’t automated at all. The lack of automated processes affects the speed of the change delivery and increases the influence of the human factor, which negatively impacts the entire company as a whole and not just the development department.

In this post I will try to explain the difference between the following processes: Continuous Integration (CI), Continuous Delivery (CD) and Continuous Deployment (CD). Most people don’t separate the last two terms, but we will discuss them separately to get a general understanding.

CI, CD and one more CD: operation principle and differences

Continuous Integration (CI)

The Continuous Integration process automates the integration checks of developer changes merged into the rest of the code.

This process might include static code analysis to detect vulnerabilities and inconsistencies with general development practices, application building and automated testing with dynamic vulnerability scanning.

Automating CI processes allows you to speed up development by eliminating routine manual checking of integration with the rest of the code and reducing the workload on the QA (Quality assurance) department due to faster identification of integration problems with the rest of the application. Also, a developer will not be able to save time by submitting changes for testing without any verification.

Continuous Delivery (CD)

This stage is used to deliver the modified version of the application to production.

For example, the process of delivering Docker images is simply loading an image to the Docker image registry and then loading it from the host machine. In systems with increased security requirements, there might also be a situation where Docker hosts do not have access to any registries, and in this case, docker save and docker load commands can be used for delivery of Docker images.

In systems that don’t use Docker, delivery can be performed through SCM, apt/yum repositories, ssh, S3-compatible storage for VM images (built with Packer, for example) and many other methods, but their application field largely depends on emerging requirements and convenience of support.

In the example above with Docker, the changes will be delivered with the new image via loading to the Docker image registry.

Automation of CD processes allows you to speed up delivery, eliminate the influence of the human factor and also make delivery more accessible to the rest of the team.

Continuous Deployment (CD)

The process is used to deploy a new version of an application to a production or testing environment. Usually, deployment is not isolated as a separate stage and is included in the delivery process. It depends on the specified requirements and the used tools, but the process implementation option is quite obvious, as a rule.

CI/CD tools

There are a lot of SaaS solutions available, and covering all of them would require another post. Let’s look at the main solutions that are easily integrated in most cases:

GitLab CI is a great option for teams that use SaaS or on-premise GitLab instance. Uses YAML to describe CI/CD processes.
GitHub Actions is a good, but a relatively new option for those using GitHub. Also uses YAML to describe CI/CD processes.
Jenkins is a project with a long history, it allows you to use Groovy to describe CI/CD processes (which is an advantage and a disadvantage at the same time for many reasons) and your own DSL in Jenkinsfile.

A detailed analysis of the processes on a fictional example

Let's imagine a possible process in a fictional IT company and the possible requirements that are made by stakeholders. Take a small IT department with development, testing, and operations teams. The workflow is organized using Git-flow, and the deployment is done on Docker hosts. Let's describe the main requirements of the parties in the table.

After collecting the requirements, we can outline how the CI/CD processes will be performed in the team:

CI Phase. Analysis

The integration process does not have to be general in all cases. It is much more convenient to describe different scenarios for each situation. Let's describe possible situations as an example:

When updating a Pull/Merge Request, a static code checking is performed for compliance with the company's coding standards, a static code analysis for possible errors and vulnerabilities, an automated unit and functional testing using stubs instead of external services.

If necessary, the image will be built for further integration with the rest of the company's services and external ones.

If we have changes in the main branch the process is similar to the above example. But there is an exception that now the image for integration is always built: for further deployment at the stand for general E2E and acceptance testing with the rest of the components.
When installing the tag, the image with the application is built for production and post-deployment smoke testing.

Why can't we build the general CI process?

To tell you the truth, it does not make any sense. If you build an image for integration testing after manual confirmation for the release branch, then we will, without a doubt, forget to start the build manually, and the QA department will check the out-of-date version of the application. It is a waste of time to conduct compliance with the coding standards and unit / functional testing on a tag version, as all the changes are already in the release branch.

The more automated tasks there are, the more worthless work will be done in the general process.

CD (Delivery) Phase. Analysis

In our case, the delivery is loading a Docker image with an application into the Registry. From the Registry the images will be loaded onto a specific Docker host during the deployment process. The Registry can be shared or separate: for the development and test environment and the production environment. It depends on the security requirements in a company.

CD (Deployment) Phase. Analysis

In our case, a deployment can be performed to the production environment by redirecting all the new HTTP requests to a new instance of the application (the maximum request time is limited within reason above for ensuring the deployment without downtime).

It is worth drawing attention to cloud hosting if you manage a small project and don’t need to create your own infrastructure. It allows you to automate project development by setting up CI/CD process.

For example, the Hostman platform will be responsible for delivering changes. A Docker image will be built in the selected branch from the new version of the code and will be automatically deployed without downtime. In our example, automation would have ended at the stage of merging the developer's changes into the release branch.

Conclusion

I hope this post helps you to clarify and understand the differences between CI and CD, as well as to see how important it is to automate these processes.

To sum it up, a CI/CD pipeline implementation is an ongoing process. It is constantly changing according to the new requirements and needs of a company. It is obvious that the CI/CD process requires additional tools and extra time. However, we can reduce costs and time by using ready solutions and services.

The decision is yours! I believe these processes automation should be integrated in every company that specializes in development of applications, products, platforms etc.

3 best alternatives to the big cloud providers

Alex Boykov — Thu, 12 Nov 2020 15:43:16 +0000

As the complexity of Cloud Computing is reaching clouds, we, as developers, are posed with problems that never existed before; deployment being one of them. Of course, one could always go for Virtual Private Servers (VPS) or (opting for more modern means) cloud services such as AWS, Azure or GCP. Sure, these providers have fulfilled their promise of easing the process of deployment to an extent, but the ever evolving nature of cloud has rendered it still hard to navigate through.

These platforms, that we could call Big Cloud Providers have gotten complex to the point it must be proven that we are worthy of their services (of course, by taking some exams; I just made it over-dramatic..) Even the simplest of them, GCP is hard to know around.

So, bye-bye BCPs…

Now, coming back to our good old VPS Providers (such as Digital Ocean, Linode, Vult…), they still demand the knowledge of additional skills like linux and sysadmin, so let’s outright label them as not-simple.

With the Big Cloud Providers and VPS Providers out of spectrum, I’ve run down three providers which I deem good enough for these times’ use:

Netlify and/or Vercel (for hosting JAM stack or serverless apps)
Hostman (for both front- and back-end apps)
Heroku (for back-end apps)

Netlify and/or Vercel

Netlify is a popular front-end hosting platform. I know what you’re thinking, and yes, I have a reason to include something such as this here in this article; the reason being that they are one of the major innovators of a new trend in web development, namely, JAM (JavaScript, API and Markup) or more popularly known as JAMstack.

Also, it is one of the easiest solutions for using serverless.
That is not even the tip of the iceberg, however. Netlify uses serverless functions, powered by AWS Lambda, for backend usage matters.

Authentication of users can easily be enabled with Netlify Identity.

And don’t get me started about CI tools and CDN...oh, sure, I must get started! Well, it acts as an abstraction layer to host, so easy that a simple drag-and-drop is all you require. Github (and other git repositories) Integration is a given feature, so all it takes for the entire application to be built and hosted in the CDN is a git push.

Advantages:

The Vendor Lock, yes. It is not a thing for most of the services (in fact, all of the ones except their extra services) in Netlify, so migrating from it should not be much of a problem. Also, their services like git gateway, identity and CMS, all of them are open source, so you could rehost them if required.
It’s one of the easiest solutions for using serverless functions. You just have to write the code and put it in a folder and netlify will take care of the rest. And even for non serverless needs (Frontend Hosting, etc.), you only have to set it up for around 5 minutes and that’s it. You don’t have to worry about anything else.
It is, as mentioned earlier, one of the best options there is for JAMstack.

Disadvantages:

Serverless, serverless and serverless -- Netlify doesn’t support anything other than serverless functions. Although it might be a really convenient way for abstracting backend infrastructures, it has its limitations (long cold boot time, etc.).
Even if you plan to use serverless, there is no inbuilt support for persistent data. Meaning, you still need to use external services (AWS S3, Cloudinary, etc.) if your website has user uploaded data/ database.
You cannot deploy real time applications as they need an event messaging system, which is not possible on Netlify.
The pricing could get a bit awry. Simply put, it’s terrible. Given that it has a very generous free plan, once you get to the premium block, the cheapest plan for $45 all the way up-to $290 doesn’t quite add up...there are other cheaper alternatives.

Hostman

Hostman uses containerized systems that run on top of AWS, GCP, Azure… but still implements them differently, in quite an easy manner. I mean, not having to write ConfigFiles( “Procfiles” as in heroku), sure is easy, isn’t it?

For most developers working with Python, Go, Node.JS, Scala or Clojure, Hostman is the ideal choice for hosting and deployment.

For deployment infrastructure, it uses a container that is running on top of AWS and DigitalOcean, which has a wide flexibility, i.e. this provider here supports horizontal as well as vertical scaling, which is a point one must not miss while talking about Hostman. Also, like Netlify, ‘push-to-deploy’ is an option here as well, so once you push the code to Github, it gets automatically updated.

Additionally, it has an automated alert system where you get emails (or through your preferred platform) in case of any failure in the CI/CD. Also, in such cases, the backup version of the application is used, so one up for you here, Hostman!

Not that it has no flaws, it has plenty, let’s break it down below:

Advantages

It supports 7 locations, be it in India, Europe or America. This helps reduce latency.
It has a very fair pricing model -- cheaper than heroku, for comparison. Also, to add to the list, it gives a free SSL certificate to all users and websites (YAY!!!). Plus, it has CDN and is free for Front-end apps.
I talked about configuration above as well: the 22 languages and frameworks require no additional configuration (not even the config-files.)
It has a built in CI/CD tool that is very easy to set up; once set up, you can just sit behind and relax.
Unlike Heroku, it has permanent storage, so no need to join additional forces with AWS or other storage services.
You can run SSH into the container directly from the website.

Disadvantages

No CLI support. A big hole they busted, but it is what it is.
Also, SQL supported readily are MySQL, MongoDB and PostgreSQL. (Limited, aren’t they?)
Unlike heroku it has no support for 3rd party extensions.

Heroku

Heroku is one of the pioneers of PAAS (platform-as-a-service) Solution.

It mostly comes in highlight due to its wide variety of useful Extensions (which include the ones for managing a database to sending emails or running cron jobs). Also,with built-in CI tools and the fact that almost all of the management tasks can be abstracted, you get a pat on the back, Heroku!!!

Advantages

Heroku has ready to use environments that allow developers to deploy code very fast.
Heroku doesn't need infrastructure maintenance; meaning, you don’t need to manage the system. Also, it has easy-to-use built-in tools for monitoring and management.
It has simple horizontal and vertical scaling.
It has a built in continuous integration tool (Heroku CI).
It is very easy to use: you could create a server in just some seconds with the Heroku Command Line.
In need of more complex features, it allows rather easy integration with other AWS products.
It also supports third party integrations through extensions.

Disadvantages

Although heroku offers a generous free tier, once you exceed the free tier, it gets expensive really fast. The free tier also has limitations where the app sleeps after 30 minutes of inactivity and the price can range for $35 per month to $500 per month without even counting the extra expenses for the 1st and 3rd party extension integrations.
Although heroku is awesome for hosting backend applications. It is not suitable for hosting frontend applications. Especially in contrast to other services that offer CDNs.
Although great for small (or medium) applications, it is not so ideal for comparatively larger applications.
It has very limited types of instances.
It has high inbound and outbound latency and has low network performance.
Although heroku offers 3rd party integrations with extensions, The extensions are limited. You can’t do much and doing it so manually is a larger hassle than it should be.

Some final words

There is no one best thing out there, only “better at this than that”. So, with the things I have mentioned in the premise, it is in best interest to seek balance between your requirements and choose accordingly.

If your thing is backend only development, Heroku is the way to go; if mostly frontend, Netlify is a better choice. If you want to combine both front- and back-end applications, clean and easy UI, use Hostman.

4 ways to deploy web apps in 2020

Alex Boykov — Thu, 22 Oct 2020 18:13:58 +0000

Application deployment comprises the steps, processes, and activities required to make an application or update available for its intended users. The manner in which you deploy an application matters a great deal as it impacts how quickly your product will respond to changes, and the quality of these changes. Today, most software developers deploy updates, patches, and new applications via a combination of manual, automated, and cloud-based processes, although, manual application deployment is being phased out.

In this post, I will examine 4 different ways in which applications can be deployed. The methods I will be considering are the most common and effective deployment techniques available today. They include:

Circle CI and Travis CI
Regular cloud hosting + Jenkins
Bitbucket pipelines
Automated cloud platforms

CircleCI and Travis CI

Continuous integration (CI) is a software development practice based on the frequent integration of the code into a shared repository. The continuous integration practice helps developers identify problems that may occur during the application development process earlier, and a lot easier. By integrating regularly, less time gets spent looking for errors, leaving more time to spend developing key features.

Circle CI and Travis CI are the two most popular CI platforms available, each with its pros and cons. The key features of Circle CI are:

It’s cloud-based, hence, requires no administration.
It has a free plan, even for business accounts.
It’s a complete out of a box solution that requires minimal configuration/adjustments.
You can trigger SSH mode to access container and resolve issues which may arise.
The caches on Circle CI require installation, minimizing unwanted dependencies thereby increasing application run time.
Circle CI is compatible with Python, Node.JS, Ruby, Java, Ubuntu, Github, Bitbucket, AWS, Docker, Azure, Slack and a couple of other applications.

Advantages of Circle CI

Fast start.
Fast setup integration with GitHub.
Lightweight and with easy to read YAML configuration.
Cloud-based thus, requires no dedicated servers.
Has a clear workflow diagram with the ability to re-run specific steps.

Disadvantages of Circle CI

Cost per user is very high.
UX is not very intuitive.
Unlike say Jenkins, customization is limited.
Its documentation is inferior to competing applications.
Takes a bit of time to get git submodules working properly.

Circle CI and Travis CI are both cloud-based applications with a YAML file configuration but unlike Circle CI, Travis CI supports a lot more languages out of the box.

Regular cloud hosting + Jenkins

Jenkins is a powerful application that allows for continuous integration and delivery of projects, regardless of the platform you’re working on. By using Jenkins, software companies can accelerate application deployment as Jenkins can build and test at a rapid rate. The Jenkins application supports the complete development lifecycle of an application from building, testing, documenting to deployment.

The Jenkins stack can be pre-configured for use on cloud via either of Google Cloud Platform, Amazon Web Services or Azure. There are single-tier templates available on Amazon Web Services or Azure with the Azure Master Slave topology providing multi-tier templates.

Advantages of Jenkins

With hundreds of plugins available on its update center, Jenkins can integrate with practically every tool in the continuous integration and delivery toolchain.
Jenkins is available for free.
Jenkins is a self-contained Java-based program that gives full control of the system.
Allows for the lunch of builds with various conditions.

Disadvantages of Jenkins

Requires dedicated servers which means extra expenses.
Needs time for configuration/customization.
Compared with modern UI trends, its interface is outdated.
Jenkins is difficult to install and configure.
Its continuous integration breaks regularly due to small setting changes.

Automated cloud platforms

Modern software teams are increasingly adopting the cloud for application deployment but deploying on cloud platforms is significantly different from on your own data center.

There are several platforms offering cloud-based application deployment. However, if you need a platform that makes it easy to deploy and operate applications based on a microservice architecture for almost any cloud, then Hostman is your best bet.

Hostman runs on AWS, GCP and Azure and in only a couple of clicks, you can launch your application because everything you need is done by default. Hostman’s deployment automation helps users implement continuous delivery on the cloud.

Its features include:

Supports 22 frameworks which means applications will run as fast as they’re deployed.
Connects to your Github, Gitlab, or Bitbucket repository and pulls the code.
Installs all dependencies, builds the code, and notifies you via Slack or Email.
Monitors activity on your Git repository and updates the service when you push the code.
No vendor lock, meaning you can switch from Hostman to other providers easily.

Advantages of Automated Cloud Platforms

They support CI/CD.
A free tier and the paid versions that begin from as low as $6.5 a month.
They shortens the development cycle and produces fewer errors.
Deployments can easily be repeated in a secure manner.

Disadvantages of Automated Cloud Platforms

There could be a feeling of loss of control with cloud-based deployment.

Bitbucket pipelines

Bitbucket Pipelines is an integrated CI/CD service, built into Bitbucket. It allows you to automatically build, test and even deploy your code, based on a configuration file in your repository. Bitbucket pipelines allow users to create a configuration file called bitbucket-pipelines.yml in their repository where they can specify branches on which they want to trigger pipelines for running builds and deployments.

Advantages of Bitbucket Pipelines

Bitbucket allows for the creation of merge rules specific to the needs of each repository.
It has robust team and project management tools.
Great pricing for small and enterprise-level companies (including a free tier).
Allows for continuous integration- meaning more people can work on the same project.
Can be integrated with JIRA.
Bitbucket pipelines make scaling easier and commits are executed on new docker images.

Disadvantages of Bitbucket Pipelines

You can’t store data for your pipelines reliably as data gets lost easily unless cached.
Per project pricing is a bit more compared with competing deployment applications.
Setting specific permissions for projects and repositories is not as intuitive as on other solutions available.

Conclusion

The above application-deployment techniques have their respective strengths, weaknesses, and learning curves. Automated cloud platforms like Hostman and other industry leaders provide many one-stop benefits.

However, the other hosting techniques offer a range of useful features and integrations with Jenkins well-proven across the industry.

This post is designed to analyze certain aspects of deployment techniques you can employ and while automated cloud deployment platforms seem like the way to go, you should do some more research to decide on what works best for you and your business.