DEV Community: Mikhail Shevtsov

Development Instruments Explained

Mikhail Shevtsov — Wed, 23 Oct 2024 13:09:29 +0000

📝 Note: Thumbnail was generated using
Flux Schnell model with help of ComfyUI;
This article was written with help of NI - Natural Intelligence
🎥 Don't have time to read? - Watch the video we created:

Development instruments 🛠️

While it’s possible to write applications using pencil and paper in practice
it’s very inconvenient. The developer has to check syntax all the time,
control changes that were made during the development process. To simplify
this work - instruments are used.

Version Control System ➕/➖

Complex applications contain millions of lines of code spread across hundreds
of files. To keep track of the changes a Version Control System (VCS)
is used. It helps to see the difference between releases and to revert
to the previous version if needed.

Most popular VCS on the market right now is GIT - developed by
Linus Torvalds. It’s distributed - meaning that for its normal operation
no server is required.

Integrated Development Environment 📄

To simplify navigation inside of the complex project source code
Integrated Development Environment (IDE) is used. Basically it’s an advanced
text editor that understands and highlights syntax of the programming language
on which the application is written. It allows developers to quickly navigate
inside of the source code and debug the application.

Debugger 🐞

Debugger is an app that allows developers to control the execution process of
the application and monitor each variable and command that is being executed.
A Step-by-Step debug of the application helps to find flaws in the execution
and business logic.

Usually the debugger app is integrated directly into IDE.

Linter ✅

Source code that is written by the developer is not required to be pretty and
easy to read, however it is highly recommended to. It simplifies the work
of the team members who maintain the projects source codes. To avoid the
tedious process of aligning code according to the project standards the Linter
app is used. It enforces rules to keep the code clean by either showing
a warning message or automatically fixing the code.

An example of most common rules for the linter are:

Line length should not exceed 80 characters;
Open curly bracket for the function should be on the next line after the function definition;
The body of the loop or conditional statement should be indented by 4 characters ;

Linter can work as a standalone application or as a module in IDE.

Frameworks 🏗️

Like with libraries a lot of functions in the applications are very common and
can be reused between applications. Framework - is a foundation for building
the application by focusing on the important parts such as business logic
without thinking about boring stuff such as user auth or file storage.
Frameworks drastically simplify and increase the speed of the development.

Example of a popular framework - Laravel. Out of box it includes
a lot of good features such as:

User authentication and authorization;
Database migrations;
Job queues;
File Storage;
Notification & email;
Events & WebSockets;

A good framework always comes with extensive documentation.

Kubernetes ⚓️

Writing a working application is only 50 percent of success.
Next 50 percent comes with app distribution and hosting.
To solve the problem of hosting web applications, smart people
from Google invented Kubernetes.

Kubernetes is a framework. Its purpose is to host your web application and
actively monitor that app replies to the incoming requests. If it stops
responding Kubernetes forcefully restarts the application.
Kubernetes also handles horizontal and vertical scaling of the application
according to the workload.

Conclusions 🚀

Understanding the instruments that you are working with is the first step
towards success. So the next time you start next project collect and use
correct tools for the job.

Source: https://blog.wiregate.io/posts/development-instruments-explained

Programming Languages Explained

Mikhail Shevtsov — Tue, 08 Oct 2024 16:43:54 +0000

📝 Note: Thumbnail was generated using
Flux Schnell model with help of ComfyUI;
This article was written with help of NI - Natural Intelligence
🎥 Don't have time to read? - Watch the video we created:

Assembly 🤖

Initially all programs were written in a binary - so called assembly
programming language. Where you literally instruct CPU what to do within
ALU. While assembly by being a low-level programming language provides
very fine control over ALU it requires programmers to actually know CPU
architecture and binary logic - it’s very hard and expensive.
Assembly provides low level optimizations that benefit execution performance.
Examples of such programs that are being developed and actively maintained
are sorting algorithms, hash functions, loops etc.
So to reduce complexity and to improve efficiency smart people invented
high-level programming languages.

📝 Example of assembly hello world app for Linux X86:

section .data
    hello db 'Hello World!', 0x0A     ; The string to print, with a newline

section .text
    global _start                     ; Entry point for the program

_start:
    ; Write the string to stdout
    mov eax, 4                        ; syscall number for sys_write
    mov ebx, 1                        ; file descriptor 1 is stdout
    mov ecx, hello                    ; pointer to the string
    mov edx, 13                       ; length of the string
    int 0x80                          ; call kernel

    ; Exit the program
    mov eax, 1                        ; syscall number for sys_exit
    xor ebx, ebx                      ; exit code 0
    int 0x80                          ; call kernel

High-level programming languages 📡

The purpose of high-level programming language is to simplify the procedure of
writing business logic using human readable text. High level programming
languages are classified as compiled and interpreted.

Compiled programming language 🏭️

Compiled programming language translates high level human readable code into
machine cod during compilation procedure.
A program that does actual compilation is called a compiler.
It’s worth mentioning that each program needs to be compiled
to specific computer architecture.
Programs compiled for X86 will not work on ARM processors and vice versa.
So compilation for specific architecture is required.
Compilation is an irreversible process.
You can’t reliably convert assembly code to high level source code.

Performance wise in majority of the cases compiled programs do execute
faster 🐇 than Interpreted programs.

Majority of compiled languages are statically typed.
Explanation follows in the next paragraphs.

Most popular compiled languages are C, C++, Rust, Objective C, C#.

📝 Hello world on written on C programming language:

#include <stdio.h>
int main() {
   printf("Hello World!");
   return 0;
}

Statically and dynamically linked libraries 📚️

Applications can perform certain typical actions such as display images,
uncompress archives and many others. While it’s possible to write all such
functions from scratch it’s impractical to do so.
For that purpose libraries are used.
Libraries help to reduce complexity of the development process by splitting
applications into modules. New features and bug fixes can be performed within
the scope of the module rather than the whole application.
The process of integrating libraries to the main application is called
Linking. Linking can be done dynamically - meaning that all libraries are
compiled separately and connected to the main application during
the runtime of the application or statically - meaning that all machine code
of the libraries is integrated into the main application binary.
Dynamic libraries usually have extension .dll for Windows and .so for Unix.

Interpreted programming language 🐍

Interpreted programming language translates high level human readable code
into machine code during execution of the program. The program that does that
is called an interpreter. Since an interpreter is also a program which
is already compiled for specific architecture of the CPU it can translate
high level code to machine language on the fly.

Performance wise in majority of the cases interpreted programs are slower 🐢
than compiled.

Most popular interpreted languages are Python, JavaScript, PHP, Ruby.

📝 Hello world on written on Python programming language:

print("Hello World!")

Typisation in the programming languages 🚧

Programming languages can be classified as statically or dynamically typed.

In statically typed programming language all variables and data structures
are pre-defined before compilation or execution of the program.
For example this means that if the developer defines variable A as string
he cannot change its value from string to a number later in the code.
This can be verified during Ahead Of Time (AOT) compilation and print
logical error. This simple technique helps to reduce the number of errors
during execution which leads to more stable programs.

In dynamically typed programming language variables can be reassigned
from one type to another. For example a variable A can first contain a number
and later can contain a string. That method simplifies the development process.

Data Structures

Variables 🪆

Variables can be integer numbers, floating point numbers, strings.
They are considered to be the simplest possible data structure.
To dig deeper variables are stored using specified addresses in the RAM.
Address is a binary number (11111111111111101011111101111111111100001101100)
of the memory cell in RAM usually represented as hexadecimal number
(0x7fff5fbff86c) for ease of reading.

Constants are the special variables whose value, after assignment,
should not be changed by the running program.

Other Data Structures 🎁

Beside Variables there are other data structures such as Arrays,
Associative Arrays, Linked Lists, Queues, Stacks and many others.
The purpose of these structures is to store data more efficiently
so it would be easier to work with the data.

Functions in the programming languages 🚦

One of the ways to simplify programming of the business logic is to use
so-called functions. Like in math where f(x) is a function which produces
some value depending on the properties of that function in the programming
functions can return values or do some stuff. Functions can accept input
arguments such as a number, a string or any other data structure and return
values or data structures or they can work without any arguments at all,
everything depends on the business logic of the function itself.

Conclusions 🚀

In reality programming languages are not as complex as everybody thinks.
If you only starting to learn programming - begin with simple interpreted
language like Python. After understanding basics - all other languages
will follow as easy as reading the syntax.

Source: https://blog.wiregate.io/posts/programming-languages-explained

OpenAI nextgen GPT

Mikhail Shevtsov — Thu, 26 Sep 2024 14:59:37 +0000

📝 Note:\
This article was generated using llama 3.1:8b model with help of
Ollama;\
Thumbnail was generated using Flux Schnell model with help of
ComfyUI;

The Future of Large Language Models: Introducing OpenAI's "o1" Series 🚀

As a tech enthusiast, I'm excited to share with you the latest development in the world of Large Language Models (LLMs). Yesterday, OpenAI, the company behind
ChatGPT, released a new series of "Thinking" models called "o1". In this article, we'll delve into what these models can do and why they're a game-changer for
the future of LLMs.

The Limitations of Traditional LLMs 🤔

Traditional LLMs work by generating the most probable next token based on the input. This straightforward principle allows them to provide decent results, but
it's not without its limitations. For instance, when faced with complex questions or tasks, these models often struggle to provide accurate answers.

One classic example is the question "How many R letters in the word 'strawberry'?" 🤔 Traditional LLMs would typically answer 2, which is incorrect. To solve
this type of question, more advanced techniques such as a "Chain of Thoughts" are required.

Introducing OpenAI's "o1" Series 🔥

The "o1" series models address these limitations by introducing "reasoning" tokens that are truncated from the output. This allows them to iterate over the
answer multiple times until they provide a well-thought-out response. The result is more accurate and contextually relevant answers.

Two distinct models are available: o1-preview and o1-mini. If you're using the API, these models can be accessed as part of your workflow.

Pricing 💸

While the "o1" series is a significant upgrade over traditional LLMs, it comes at a price. The cost for using these models is higher than their predecessors:

$15.00 per 1 million input tokens and $60.00 per 1 million output tokens for o1-preview
$3.00 and $12.00 for o1-mini model

However, OpenAI plans to release the "o1" series for free ChatGPT users in the near future.

What's Next? 🔮

The "o1" series is not a replacement for traditional LLMs but rather an addition that solves more complex tasks. In the world of Wiregate, we firmly believe that
such models will eventually replace all other simple models.

What are your thoughts on the future of Large Language Models? Share your opinions in the comments below! 💬

Want to learn more about this topic? 🔍

Check out our blog for more tech-related news and articles (https://blog.wiregate.io)
Visit OpenAI's website for more information on the "o1" series:

Stay tuned for more updates on this topic! 🚀

Source: https://blog.wiregate.io/posts/openai-nextgen-gpt

Avoid GitHub Actions!

Mikhail Shevtsov — Thu, 26 Sep 2024 14:45:37 +0000

📝 TLDR: Don’t use GitHub Actions as it’s overcrowded with unnecessary
abstractions and False sense of security. Use GitLab CI as the most transparent
CI ever existed.\
🎥 Check out the video we created:

Introduction

Back in 2014 I started to poke around GitLab CI.
At the time GitLab was pretty new and they just recently added that feature 🚀.
It looked very logical and structured ⚙️:

Place the .gitlab-ci.yml file inside of the repository;
Define the jobs which are simple shell scripts and on each commit your pipeline is triggered and script runs;
Check the results in a nice Web UI;

Pretty straightforward. This was my first encounter with CI/CD systems.

GitLab CI

For the past 10 years I’ve encountered many other CI systems.
Some of them were straight legacy like Jenkins or Buildbot
some others were simple clones of Travis CI

🤫 Psst:GitLab CI actually was heavily inspired by Travis CI

such as CircleCI or Drone CI.
But these systems are cumbersome to manage.
Eventually we always end up using GitLab CI.

Late to the Party

While we were using GitLab CI in many different ways I always wondered why
GitHub didn't introduce any CI system as it was such a logical thing to do.
And they did in 2018! Meet Github Actions. Almost 4 years later.
You might be wondering if they did a breakthrough in
Continuous Integration space.
Unfortunately no 🤦.
They took the same approach using YAML as base
and placing jobs inside of the repository.

Me Me Me… Me too!

For the past 6 years I’ve never had a chance to actually try Github Actions
in "Action" (pun intended).
Quick glimpse on the syntax did show that it looks
very similar to repo YAML based CI systems - but syntax is quite abstract and
not very transparent.

“Ok… Then… Nothing that hard… But still very strange…” - I thought 🤔

The Action!

At one sunny summer day of 2024 I was forced to do a rather simple workflow
that I did hundreds of times using GitLab CI:

Build Docker image;
Push image to Container Registry;
Deploy image using HELM Chart to Kubernetes cluster;

“Nothing complicated.” - I thought 😃
But this is where the fun starts.

Fun #1

Abstractions… Abstractions… and more abstractions.
In order for the pipeline to work and do simple things I needed to understand
a lot of wrappers around simple tools that I use on a daily basis.
Some genius thought It’s a good idea to create “actions”.
They require you to code the “action” in the separate repository.

🤯 Why? Why? ...

Docker build and push for example. This is a simple
one shell command that does all of this. You don’t need to abstract that thing.
That is overcomplicated.

Fun #2

It seems that in order to push/pull Docker image to GitHub Container Registry
I need to use my Personal Access Token 🤬 GitHub doesn’t provide native way
to create a simple Deploy Token that isn't bound to a GitHub user account.
So by simply removing a user from repo you break access from Kubernetes
to GitHub Container Registry 🫤

Fun #3

It also was a shocking thing 😱 to me that when a Secret is added to
the Repository it's impossible to view it and change after.

“It is for the SECURITY!” - you might shout ‼️

But in reality this is not security - it is dumb! ☹️

Any DevOps/Developer with access to the cluster or app who understands
how CI/CD works and the workflow can extract these secrets without any problem.
For the professional it’s not a problem it's just an inconvenience.

Conclusion

I’ve managed to get it working but still… So much hassle.
I will never ever agree to work with GitHub Actions.

On the bright side - GitLab is still the best and gives you simple
and transparent tools to do your development.

Use Gitlab for god sake‼️

Source: https://blog.wiregate.io/posts/avoid-github-actions

Jedari Kubernetes Migration Journey: A Success Story

Mikhail Shevtsov — Thu, 26 Sep 2024 14:42:28 +0000

As a co-founder of Wiregate, I'm excited to share with you the incredible
success story of our client company, Jedari, and their journey to migrating
their application to Kubernetes. This project was a thrilling example of how
modernization can lead to significant cost savings, improved scalability, and
enhanced reliability.

About Jedari

At its core, Jedari is more than just a platform; it's a movement that empowers
creators and professionals globally with fully-branded, private social
networks. Their mission is to champion freedom of expression, data ownership,
and community engagement, ensuring every voice and brand can reach its full
potential in the digital landscape.

The Challenge

Before migration, Jedari faced several issues that hindered their growth:

High hosting costs: Their classic servers were racking up an astonishing $8,000 per month in AWS hosting fees.
Inability to handle high traffic: The existing infrastructure couldn't withstand the demands of high bandwidth traffic, leading to downtime and frustrated users.
Manual update rollouts: Updating their applications was a manual, time-consuming process that introduced risks and delays.

The Solution

Our team at Wiregate worked closely with Jedari to design and execute
a strategic migration plan. Here's an overview of the journey:

Month 1: Dockerization and Local Development
Months 2-5: Stateless Architecture and Production Clusters
Month 6: Monitoring and Observability

The Tools

To achieve this transformation, we leveraged the following tools:

Gitlab: On-premises source code storage and Docker container registry.
Gitlab CI/CD: Automated pipelines ensured seamless updates and deployments.
Terraform: Infrastructure as Code (IaC) for automated infrastructure management.
AWS EKS: DEV, STAGE, and PROD Kubernetes clusters were deployed on AWS Elastic Container Service for Kubernetes.
Minio: Local development environment for efficient testing.

The Results

The impact of this migration was staggering:

Reduced hosting costs: Jedari's monthly AWS hosting bill decreased to under $3,500.
Automated infrastructure management: Terraform ensured that infrastructure changes were consistent and repeatable.
Zero-downtime updates: Automated update rollouts using Gitlab CI/CD meant no more downtime or delays.
Horizontal scaling: Kubernetes autoscaling enabled Jedari to handle increased traffic without issues.

Conclusion

The Jedari Kubernetes migration journey was a resounding success. By
modernizing their infrastructure, Jedari achieved significant cost savings,
improved scalability, and enhanced reliability. As a co-founder of Wiregate,
I'm proud to have played a part in this transformation. If you're facing
similar challenges, don't hesitate to reach out – we'd be happy to help you
embark on your own Kubernetes migration journey!

Schedule a Consultation

Let's work together to scale your business and achieve success!

Source: https://blog.wiregate.io/posts/jedari-kubernetes-migration

Why GitLab On-Premises?

Mikhail Shevtsov — Thu, 26 Sep 2024 14:40:30 +0000

In today's fast-paced digital world, managing code efficiently and securely is
paramount for development teams. For organizations considering a robust
solution, GitLab On-Premises stands out for several compelling reasons.
Here, we will explore the advantages that come with deploying GitLab on your
own infrastructure.

Ownership and Control

One of the most significant benefits of using GitLab On-Premises is ownership
of your code. By hosting GitLab within your own data center or cloud
environment, you maintain complete control over your repositories, workflows,
and access permissions. This is especially important for businesses working
with sensitive data or regulated industries, as it mitigates the risk of
unauthorized access and ensures compliance with data protection regulations.
You can set your own security protocols, making GitLab not just a platform for
collaboration, but a fortress for your intellectual property.

Enhanced Security

With GitLab On-Premises, organizations can implement their own security
measures tailored to their specific needs. Unlike cloud solutions where data is
shared across multiple clients, an on-premises installation reduces the risk of
data breaches and unauthorized access. By controlling firewalls, encryption,
and network access, teams can build a secure environment that protects their
assets from external threats. This level of customization makes GitLab a
preferred choice for enterprises prioritizing security.

Customization and Integration

GitLab is designed to be flexible and can seamlessly integrate into existing
workflows, especially when hosted on-premises. Organizations can customize the
GitLab environment, adapting it to their unique development processes.
In addition, businesses can leverage GitLab’s built-in CI/CD capabilities to
automate testing and deployment without compromising their development
environment. With tools such as Docker and Terraform available within GitLab,
managing dependencies and infrastructure directly alongside your code further
enhances productivity.

Compliance and Regulatory Needs

For many organizations, particularly those in healthcare, finance, or
government, compliance with regulatory standards is non-negotiable. Hosting
GitLab On-Premises enables businesses to establish their own compliance
measures, ensuring that all workflows adhere to industry requirements. With
full control over data storage, processing, and access management, companies
can create audit trails and logging that satisfy compliance standards, all
while avoiding potential pitfalls associated with third-party cloud services.

Cost-Effectiveness in the Long Run

GitLab On-Premises offers a low-cost solution that can lead to significant
long-term savings. By eliminating ongoing subscription fees typically
associated with cloud services, organizations can allocate resources more
effectively. Additionally, operational costs can decrease over time,
particularly for teams managing high-volume projects that require robust CI/CD
and collaboration tools.

Conclusion

In summary, GitLab On-Premises is ideal for organizations that value ownership,
security, customization, and regulatory adherence. By choosing to host GitLab
within their infrastructure, businesses can streamline their workflows, enhance
security measures, and ultimately maintain a competitive edge in the demanding
world of software development. Whether you're a small startup or a large
enterprise, GitLab On-Premises provides the solid foundation needed for
efficient coding and collaboration. Embrace the opportunity to take control of
your development process — your code deserves it.

Source: https://blog.wiregate.io/posts/why-gitlab-on-premises

Why to use Kubernetes instead of Docker Compose?

Mikhail Shevtsov — Thu, 26 Sep 2024 13:42:11 +0000

In the evolving landscape of software development, the choice of tools and
frameworks significantly influences the success of application delivery.
At the forefront of this transformation is Kubernetes, an open-source container
orchestration platform. So, why should businesses consider using Kubernetes
over simpler solutions like Docker Compose in production environments?

High Availability and Fault Tolerance

One of the primary reasons to choose Kubernetes is its robust capacity for high
availability and fault tolerance. While Docker Compose excels in local
development by spinning up project stacks, it isn’t built for production.
Kubernetes, on the other hand, automates many essential processes, ensuring
that applications remain up and running even during failures.
With self-healing capabilities, Kubernetes automatically replaces failed
containers, thus minimizing downtime.

Efficient Application Lifecycle Management

Kubernetes takes on the heavy lifting of application lifecycle management.
It provides seamless monitoring, allows for updates without service
interruptions, and incorporates effective load balancing. This functionality
is crucial for maintaining a smooth user experience in production environments
where performance and reliability are paramount.

Scalability: Horizontal vs. Vertical

Understanding scaling strategies is vital when deploying applications.
Vertical scaling involves enhancing a single instance’s resources—think larger,
faster servers. However, this method can hit limits as it depends on the
resource capacity of a single machine. Kubernetes facilitates horizontal
scaling, where multiple replicas of an application can be spun up to handle an
increased load. This not only enhances performance but also contributes to high
availability, ensuring that if one instance fails, others can take over
seamlessly.

The Right Tool for the Job

It's important to note that Docker Compose is not obsolete. It serves a crucial
role in development environments, making it an excellent choice for local
testing and setup. Many development teams leverage both Docker and Docker
Compose during the creation phase before transitioning to Kubernetes for
production. Each tool has its strengths, and the choice between them should be
guided by the specific needs of the deployment environment.

Conclusion

In conclusion, Kubernetes provides essential features that are critical for
modern application deployments. Its capacity for high availability, fault
tolerance, and efficient lifecycle management makes it the premier choice for
organizations aiming to scale their applications effectively. While Docker
Compose remains valuable for local development, integrating Kubernetes into
your production strategy can significantly enhance your application’s
reliability and performance. Embrace the shift towards container orchestration
with Kubernetes and keep your applications "Up and Running."

Source: https://blog.wiregate.io/posts/why-to-use-kubernetes