<Wrapper emptyHeading backgroundColor="gray">
  <ContentWrapper title="Cloud Team VS Freelancers: Who's Better to Work With?">
    Nowadays, your promising team is no longer confined to your local developers or random individual freelancers. The important question is, how to hire the best developers with a guarantee of services' quality? I’d like to show you what we personally do to achieve it and what advantages we have as a result. 
    Let me begin with a small introduction to our team. We’re a “cloud team”. When you need some web project to get done and you’d like to be sure that it will be done properly and by the most effective way, you definitely should try our “cloud team” in work, actually we’re consists of developers who could become freelancers but they chose to be a part of our team by some reasons I’d like to clarify here. Such developers’ collaboration is very efficient and it works very well for 8 years pleasing our developers as well as our customers.

    I'd like to say that I know very smart, talented, motivated and experienced individual freelancers, and I don't like to offend anyone, but I think there are some obvious cons that you may experience when you hire an independent freelancer and you should take these cons into consideration when you do that. We think that you have to ask yourself some questions that I mention here before hiring a freelancer.

    <Title class="contentTitle" type="h2" id="sickness">1. Sickness</Title>

    A freelancer can get sick, it just happens and usually, it happens unexpectedly. What if a hired freelancer gets sick or even suddenly disappears? Remote agency usually have some developers in reserve, who are always ready to replace a sick developer for some time, so you won’t even notice. The human factor of imperfection won’t affect your business by any means!

    <Title class="contentTitle" type="h2" id="vacation">2. Vacation</Title>

    A freelancer can have a vacation and he definitely should get a vacation once or twice per year at least, but most of the projects have deadlines, and usually, deadlines aren’t going to take freelancer’s vacation without consequences. You don't have to think about it, we'll take care that our developer will get a vacation and we’ll provide you with a smooth temporary replacement.
    What if an independent freelancer would go on vacation? How would you replace him for 2-4 weeks?

    <Title class="contentTitle" type="h2" id="education">3. Education</Title>

    **We have a road map that each developer should pass with a certain period of time, each step out of 5 mostly looks like an exam, most of the time it takes about 3 months of preparations and 5-8 hours of examination in the appointed day. It includes but not limited to:**

    * Web: HTML, CSS, JS, PHP, Databases + different languages and frameworks (depends on the developer’s specialization);
    * Theory: Operating systems, Web technologies, Algorithms, and Data Structures, OOP;
    * Tools and side hard skills: Task tracking tools, Deployment tools, Cloud computing services, Development environment, Debugging tools, Virtualization(Vagrant/Docker), Command Line Interface, Dependency management, Best practices of making project's documentation and project's estimation;
    * Soft skills: Communication, time management, development's methodology, licenses, and NDAs;

    So we encourage developers for growth very much and we have a lot of successful examples of developers transformation from Junior to Senior for 3-5 years. Is there any guarantee that a freelancer will grow day by day? Even experience is not always equal to real growth.
    I understand that your main intention is to successfully implement your project, not freelancer’s education, but if a developer doesn't deepen and broaden his knowledge, there is a high chance that he tries to solve your business problems by not the most efficient way. Some freelancers neglect theoretical basis knowledge and they not always intend to be involved in any form of education because often when you learn you don't earn money and this state of things is not an option for each freelancer.

    <Title class="contentTitle" type="h2" id="technology">4. Technology stack</Title>

    This point is a direct consequence of the previous one. When you come to a freelancer his main intention could be to choose a technology stack that he has already known even if it’s not the most efficient way to develop your project. He could have no motivation to learn new technologies since it takes a lot of time, so he may try to convince you to use the one that he’s already experienced with.
    Our “cloud team” has experts of various technology’s stacks and all together we always try to choose the most efficient option during the initial stage of the project’s assessment, we always can make an assessment for different technologies stacks describing their pros and cons with all specificity regarding to your project to show you the big picture from different sides.

    <Title class="contentTitle" type="h2" id="support">5. Support</Title>

    Each of our developers has a mentor who has a Master's Degree or Ph.D. in Computer Science and more than 10 years of commercial experience. Even the most experienced freelancer can make a mistake and an extra pair of eyes into the code, simple advice or complete code review are essential despite the years of experience.
    Most freelancer work at home all alone without encouraging advice from his colleagues as well as without an opportunity to discuss his technical decisions with more experienced developers, so it can affect their quality of code and motivation. We insist that our developers should work from our office hand by hand with other developers. It motivates them much more, they have a chance to solve difficult problems quite fast if they get stuck, they can discuss a problem with teammates to find the best solution and it allows us to put our finger on the pulse.

    <Title class="contentTitle" type="h2" id="team">6. Team</Title>

    We have 30 developers in our “cloud team”. You can find back-end, front-end, full-stack developers amongst them, but besides we have QA specialists, web designers, and UI/UX designers. We’re a team, a large and powerful unit! If your project would be expanded and you need an extra pair of “coding hands” or you need some design/QA stuff to do, we can guarantee that we would help you with it. A new assigned developer will be the one who is working in the same room with developers who is already working on your project, they already know each other very well and it makes the introduction process of new developers for your project significantly smoother.
    If you need more than 1 developer or you have some work to do for a designer, you have to gather them all one by one in the hope of they will find common ground without pointing fingers at each other if something goes wrong.

    Even if a freelancer has a lot of positive feedbacks you can not say for sure that your project will be the one where he won't get sick, go to vacation, lose motivation or just disappear. 75% of our projects are from clients who have come to us after they had a huge disappointment after working with independent freelancers. Usually their main argument to hire a freelancer was the lower price, but they often lose a lot of time and money, usually, their only option is to rebuild everything from scratch or to make so significant code’s refactoring that would be equal to development from scratch.

    <Title class="contentTitle" type="h2" id="checklist">Checklist: “Before you’re going to find an independent freelancer”:</Title>

    **Here are some points:**

    * What if a hired freelancer gets sick or even suddenly disappear?
    * What if a freelancer would go on a vacation? How would you replace him?
    * Is there any guarantee that a freelancer expands his knowledge day by day to make your web or mobile app works better and better as a result?
    * Are you sure that the technology stack an independent freelancer has chosen for your project is the most appropriate one?
    * Are you sure that a freelancer wouldn’t spend an extra 10 hours because he’s stuck and there’s no one to help him?
    * What if one day you need more developers or design’s/QA work for your project?
  </ContentWrapper>
</Wrapper>
<Wrapper title="Related articles"
         size="full"
         backgroundColor="gray">
  <SliderS1>
    <div image="/images/blog/drupal_art.png" link="/blog/new-drupal">The "Old" Drupal: When It Becomes a Problem, and What to Do About It</div>
    <div image="/images/blog/load_art.png" link="/blog/high-load">High Load on Websites: Why Is It of Importance Not Only for Programmers?</div>
  </SliderS1>
</Wrapper>
<Wrapper title="Tell us about your project"
         backgroundColor="black"
         id="contact">
    <FormF1/>
</Wrapper>


Alexander Gurov, Business Development Officer 

Cloud Team VS Freelancers: Who's Better to Work With?

<Wrapper emptyHeading backgroundColor="gray">
  <ContentWrapper title="High Load on Websites: Why Is It of Importance Not Only for Programmers?">
    Whether you’ve pulled off a great ad campaign or published a super-topical article which made the first few pages of search engine results, one of the measures of your success is an increase in relevant traffic to your website. The notion of increasing traffic to their site makes product managers and service marketers happy: their thoughts immediately turn to increased revenues from advertising, growth in sales (if this is an online store or media with a paywall), and more social mentions and repeat visitors. Could there be any downsides? Well, yes, there could, if your service isn’t ready for the increased load. 

    Every user who navigates to your resource and clicks on something, or even just opens a page, creates a load on computing power. If this load on the server increases, and you haven’t made provisions for flexible scaling of your server capacity as part of your project, your equipment ends up pushed to its limits. The result is that your applications’ performance suffers: in layman’s terms, your website or app is slow. You can’t define “high load” with a single number: this is a problem that could affect both a little WordPress blog and a giant like Facebook. The critical number of users will be different for different projects. 

    <Title class="contentTitle" type="h2" id="signs">What are the Signs of Excessive Load?</Title>

    To make the phrase “high load” less abstract, let’s take a look at the issue through the eyes of a user: pages load slowly, you get 502 and 504 errors and database errors, pages don’t open, submissions don’t get saved. Someone looking at the site analytics at that moment would see the page views per visitor falling, the bounce rate increasing, and the site’s search engine ranking decreasing. 
    A more specialised metric which engineers might notice increasing when a site is slow is TTFB, or time to first byte. This is the time that elapses from the moment a browser starts to send a page’s request to the moment it receives the first byte of information back from the server. Poor TTFB is a pretty sure sign of performance issues.


    <Title class="contentTitle" type="h2" id="problems">What Can be Done to Avoid Problems?</Title>

    We’re talking about the kind of load generated by service users, and most of this is predictable. Given the consequences and losses that could result from the website not working as it should, the team responsible for user interaction should always assess whether any actions they’re about to take will generate a spike in traffic. If you’re preparing an ad or SMM campaign, having a sale, or sending out a newsletter which will attract a lot of traffic to the site, tell your engineers what your plans are. Together, you’ll be able to assess whether the increased load you’re expecting will be critical for your system. 

    There are a few ways you can increase the load your site can cope with. You can scale up your system by increasing its computing power, i.e. buying new servers or upgrading your web hosting plan. Another approach would be to speed up your system by adjusting its cache settings and optimising the code it runs (you can read about the many and varied things caching can do here). The solutions you employ can vary depending on the volume of traffic you’re expecting, the type of load (one-off or gradually increasing), and your site’s most frequently-used functions. Increasing your site’s resilience isn’t just a problem for engineers: there are also economic considerations. As your project grows, the cost of scaling increases. To reduce this cost, you should hire experienced engineers and carry out a thorough analysis of your system. 

    Adapting your system to increasing loads is a natural stage in a digital project’s evolution. This article hasn’t touched on the kind of increased load that can occur for reasons that wouldn’t be on a non-techie’s radar: security issues, web crawlers, suboptimal database setup, etc. If the engineers attached to your project are doing their job, these kinds of issues will be resolved without affecting other people involved in the workflow. At the same time, though, to avoid the problems this article has discussed, businesses should forecast their growth so the necessary tech can be put in place in good time.
  </ContentWrapper>
</Wrapper>
<Wrapper title="Related articles"
         size="full"
         backgroundColor="gray">
  <SliderS1>
    <div image="/images/blog/drupal_art.png" link="/blog/new-drupal">The "Old" Drupal: When It Becomes a Problem, and What to Do About It</div>
    <div image="/images/blog/freelance_art.png" link="/blog/cloud-team-vs-freelancer">Cloud Team VS Freelancers: Who's Better to Work With?</div>
  </SliderS1>
</Wrapper>
<Wrapper title="Tell us about your project"
         backgroundColor="black"
         id="contact">
    <FormF1/>
</Wrapper>


Alexander Gurov, Business Development Officer

High Load on Websites: Why Is It of Importance Not Only for Programmers?

<Wrapper emptyHeading backgroundColor="gray">
  <ContentWrapper title="The “Old” Drupal: When It Becomes a Problem, and What to Do About It">
    Drupal is a piece of content management software used to create web apps for media, the public sector, EdTech, healthcare, e-commerce and other sectors. It is generally chosen for its scalability (it adapts well to high load), flexibility (numerous out-of-the-box solutions are available for various business tasks) and its user-friendly content management system. Over its almost 20-year history, a strong community has sprung up around this open-source framework, and 3 June 2020 saw the release of the ninth major version of this CMF (content management framework).
    
    <Title class="contentTitle" type="h2" id="difference">The new version and the old versions: what’s the difference, and what do they offer?</Title>

    Over time, approaches to development and the IT ecosystem as a whole change a lot, and major versions of software reflect this. For instance, the previous big release, Drupal 8, which appeared in 2016, differed from earlier versions in having an object-oriented back end using Symfony components. Implementing the standards and technical capabilities provided by Symfony-based development enabled Drupal’s creators to concentrate on perfecting Drupal-specific features. This made Drupal 8 more attractive for developers and more effective for tackling business challenges.

    New Drupal releases are shaped both by global trends in web development and by changes in the components which Drupal is based on. Older versions of Drupal had fewer dependencies and links to other software, so the framework used to be developed more sporadically: a new major version would come out once every few years, and it would not be backward-compatible with the previous version. This meant developers of Drupal modules would have to almost completely rewrite their code for the new core version. To make use of the new version’s functionality, users would have to independently migrate their sites to the new version. Nowadays, to make Drupal and Symfony work better together, Drupal has adopted a six-month update cycle, gradually introducing new features and marking certain elements as legacy elements.

    <Title class="contentTitle" type="h2" id="old-versions" >Old versions’ end-of-life</Title>

    The main catalyst for the release of Drupal 9 was that support for Symfony 3, which Drupal 8 depends on, is due to come to an end in 2021. When support for an older version of a piece of software is discontinued, official updates, bug fixes and security updates are no longer released, which, over time, makes the system less reliable. For most businesses, it is old versions' end-of-life that is the most important reason for migrating to a new one. Self-supporting security and functionality of legacy software entails risks and increased costs.

    Previously, Drupal's 7 end-of-life was also scheduled for November 2021. Despite the fact that more than half of Drupal projects are made on this version, its support runs counter to the development plans of the framework. But on June 24, 2020, the deadline was shifted. Given the impact of COVID-19 on budgets and businesses, the Drupal community decided to extend Drupal 7 support until November 28, 2022. Migrating from Drupal 7 is significantly more expensive than migrating from version 8 to version 9. An additional year will allow numerous Drupal 7 users to prepare more thoroughly for the last big migration.

    <Title class="contentTitle" type="h2" id="migration">The last big migration</Title>

    Thanks to the way updates are currently handled, the transition from Drupal 8 to Drupal 9 should be smooth and straightforward, as should all other updates planned for the foreseeable future. It became possible thanks to the architectural similarity between the systems. However, moving an old site using Drupal 7 over to the new core will necessitate major reworking of the site’s architecture and data model. Essentially, this means creating a new site, although this should be less work than re-platforming or creating a site from scratch. Migrating site layouts and any custom functionality written for Drupal 6 or Drupal 7 could take as much as 80% of the time it initially took to create them.

    Despite the existence of tools which should make this process easier than when Drupal 8 had only just appeared, migration remains time-consuming and costly. Some companies aren’t prepared to make this kind of investment and use legacy software for years, maintaining the system themselves or outsourcing developers. For instance, although support for Drupal 6 ended four years ago, data from 2020 on the usage of Drupal cores suggests that around 3% of projects are still using Drupal 6 or older versions. This approach is fair enough, but it creates a number of bottlenecks.

    <Title class="contentTitle" type="h2" id="problems">What problems might users of legacy versions run into?</Title>

    <Title class="contentSubtitle" type="h3" id="security-issues">1. Security issues</Title>

    Security issues and vulnerabilities occasionally come to light in both old and new software. The difference is in who has to deal with them. Responsibility for the security of the current version of Drupal is assumed by its developers: they identify potential vulnerabilities and release free security updates. For end users, installing updates is a routine task, whereas independently monitoring and fixing security problems in a legacy system requires attention and manual labour. It’s also important to remember that Drupal exists within a whole ecosystem (PHP, its extensions, Drupal modules and third-party libraries). Having lots of old, unsupported elements in a system always increases the risk of losing data—and your users’ trust.


    <Title class="contentSubtitle" type="h3" id="technical-issues">2. Technical issues and limitations</Title>

    If you’re not bothered by potential security threats, technical limitations can make your life difficult right here and now. First, because the third-party services you need don’t “get along” with your software, you’ll have to write integrations yourself and configure them to take account of older systems’ platform particularities. Second, you’ll have to hand-configure functionality that’s often available in modules in later versions. Third, even if the module you need exists, it’s not going to get updated, so you’ll have to put in the work to keep it stable yourself: third-party services’ APIs occasionally change. Billing, inventory accounting, any CRM, ERP, logistics management, etc.—the more complex your product is, the more elements you’ll have to continuously monitor.

    <Title class="contentSubtitle" type="h3" id="loss">3. Loss of system flexibility and scalability</Title>

    Supporting legacy software means a lot of custom code, and the flexibility and scalability of your system is going to take a hit from that kind of approach to development. One of the main advantages of Drupal is the abundance of different modules, which make experimenting with your product quicker and cheaper. However, there are not enough modules compatible with older versions to cover all of your current business needs. When the market changes fast and your users (clients, marketing experts, editors) need new things from your system, you won’t be able to make these changes as fast as those of your competitors who are using out-of-the-box solutions.

    <Title class="contentSubtitle" type="h3" id="issues">4. Issues with business development.</Title>

    If you want to receive state investment or subsidies, your products have to fulfil certain requirements, including technical ones. Drupal 6 and earlier versions don’t meet these requirements, as they don’t tick the boxes for service security. The cost of support and limited potential for making the changes we described above will also make your product unattractive to investors.

    <Title class="contentSubtitle" type="h3" id="high-cost">5. High cost of support.</Title>

    The code underlying Drupal 6 and Drupal 7 doesn’t conform to modern standards, so there are far fewer developers out there who can do a good job of supporting your product’s performance and security than there are for newer software. What’s more, these are mostly experienced developers with a high hourly rate—and you might end up needing a lot of hours. You might also run into problems with finding support documentation for older versions and with their compatibility with the modern ecosystem. Custom code is always more unreliable, more costly, and more labour-intensive.

    <Title class="contentSubtitle" type="h3" id="need-to-migrate" >How do I know if I need to migrate my product?</Title>

    Despite the risks this article has outlined, we’re not saying that everyone definitely has to make the move right away. You can only make a rational assessment of how urgent it is for you to transition to Drupal 9 by taking into account the specifics of your site and your future plans for it. The November 2021 and November 2022 deadlines gives you plenty of time to evaluate whether you need to make the move, work out how much it will cost, and start working on it in a careful, orderly way. Here are a few things you should take into account to make a comprehensive assessment:

    **Are you expecting to make changes to the design, add new functionality, engage in marketing activities, or see an increase in user numbers? If so, compare the capabilities of the new system and your current system, and the cost of development in both cases.**

    * Could a more advanced system help you to cut down on manual labour? For example, Drupal 9 includes Layout Builder, which lets content managers create page designs without relying on programmers. It’s looking like Drupal is increasingly moving towards making things as simple as possible to use and automating everything, even updates. Maybe you’d recoup the costs of moving to the new Drupal sooner than you think?
    * Is the speed with which you can make changes important to you? What advantages might the ability to make quick changes have for you in the future?
    * What might the consequences be of your system getting hacked? How likely is this? Are you abiding by all the laws around handling personal data?
    * What’s the quality of your code like now? The cost of migration, and the cost of not migrating, are largely dependent on the current state of your site.

    Don’t forget that using old technologies is a sort of technological debt which grows over time and is highly likely to create problems when you try to support and develop your product down the line. Changing standards are not a problem; they’re part of the technological evolution which makes creating reliable, high-performance web products easier.
  </ContentWrapper>
</Wrapper>
<Wrapper title="Related articles"
         size="full"
         backgroundColor="gray">
  <SliderS1>
    <div image="/images/blog/load_art.png" link="/blog/high-load">High Load on Websites: Why Is It of Importance Not Only for Programmers?</div>
    <div image="/images/blog/freelance_art.png" link="/blog/cloud-team-vs-freelancer">Cloud Team VS Freelancers: Who's Better to Work With?</div>
  </SliderS1>
</Wrapper>
<Wrapper title="Tell us about your project"
         backgroundColor="black"
         id="contact">
    <FormF1/>
</Wrapper>
