When we think of how some property (e.g. your address or
salary) changes over time, we usually think of it as a linear sequence of
changes. But surprisingly often, it can get rather more tangled than that,
in a way that can often confuse computerized records.

I can illustrate all this with a simple example:

• We are handling payroll for our company. We run the payroll for our
  company on February 25, and our employee Sally is paid according to her
  monthly salary of $6000.
• On March 15 we get an apologetic letter from HR telling us that, on
  February 15th, Sally got a pay raise to $6500.

So what should we answer when we’re asked what Sally’s salary was on
February 25? In one sense we should answer $6500, since we know now that that
was the rate. But often we cannot ignore that on Feb 25 we thought the salary
was $6000, after all that’s when we ran payroll. We printed a check, sent it to
her, and she cashed it. These all occurred based on the amount that her salary
was. If the tax authorities asked us for her salary on Feb 25, this becomes
important.

The Two Dimensions

I find I can make sense of much of this tangle by thinking of time as
two dimensions – hence the term “bitemporal”. One dimension is the
actual history of Sally’s salary, which I’ll illustrate by sampling on the
25th of each month, since that’s when payroll runs.

date	salary
Jan 25	6000
Feb 25	6500
Mar 25	6500

The second dimension comes in as we ask what did we think Sally’s salary
history was on February 25? On February 25th we hadn’t got the letter from
HR, so we thought her salary was always $6000. There is a difference between
the actual history, and our record of the history. We can show this by
adding new dates to our table

record date	actual date	salary
Jan 25	Jan 25	6000
Feb 25	Jan 25	6000
Mar 25	Jan 25	6000
Feb 25	Feb 25	6000
Mar 25	Feb 25	6500
Mar 25	Mar 25	6500

I’m using the terms actual and record history for the
two dimensions. You may also hear people using the terms valid, or
effective (for actual) and transaction (for record).

I read the rows of this table by saying something like “on Mar 25th, we
thought Sally’s salary on Feb 25th was $6500”.
Using this way of thinking, I can look at the earlier table of Sally’s actual history,
and say that more precisely it’s Sally’s actual history as known (recorded)
on March 25.

In programming terms, If I want to know Sally’s
salary, and I have no history, then I can get it with something like
sally.salary. To add support for (actual) history I need to use
sally.salaryAt('2021-02-25'). In a bitemporal world I need
another parameter sally.salaryAt('2021-02-25', '2021-03-25')

Another way to visualize this is to make a plot where the x axis is
actual time and the y axis is record time. I shade the region according to the
salary level. (The shape of the plot is triangular since there’s we’re not
trying to record future values.)

With this plot, I can make a table for how actual history changes with
each run of payroll on the 25th. We see that the Feb 25 payroll ran at a
time when Sally had no raise, but when the Mar 25 payroll ran, the raise was
known.

Changing the Retroactive Change

Now consider another communication from HR

• April 5: Sorry there was an typo in our previous email. Sally’s raise
  on Feb 15 was to $6400. Sorry for the inconvenience.

This is the kind of change that makes angels weep. But when we think of
it terms of bitemporal history, it’s not that difficult to understand.
Here’s the plot with this new bit of information.

The horizontal lines, used for the payrols, represent the actual history
at a certain point in record time. On April 25 we know Sally’s salary
increased from $6000 to $6400 on February 15. In that perspective, we never
see Sally’s $6500 salary because it was never true.

Looking at the diagram, what does a vertical line mean?

This represents our knowledge of the value at a certain date. The table
indicates the recorded salary for February 25th, as our knowledge
changed over time.

Using Bitemporality

Bitemporal history is a useful way of framing history when we have to deal with
retroactive changes. However we don’t see it used that often, partly
because many people don’t know about the technique, but also because we
can often get away without it.

One way to avoid it is to not support retroactive changes. If your
insurance company says any changes become in force when they receive your
letter – then that’s a way of forcing actual time to match record
time.

Retroactive changes are a problem when actions are based on a
past state that’s retroactively changed, such as a salary check being sent
out based on a now-updated salary level. If we are merely recording a
history, then we don’t have to worry about it changing retroactively – we
essentially ignore record history and only record actual history. We may
do that even when we do have invariant action if the action is recorded in
such a way that it records any necessary input data. So the payroll for
Sally could record her salary at the time it issues the check, and that’s
enough for audit purposes. In that situation we can get away with only the
actual history of her salary. The record history is then buried inside her
payroll statements.

We may also get away with only actual history if any retroactive
changes are made before an action occurs. If we had learned of Sally’s
salary change on February 24th, we could adjust her record without running
into before the payroll action relied on the incorrect figure.

If we can avoid using bitemporal history, then that’s usually
preferable as it does complicate a system quite significantly. However
when have to deal with discrepancies between actual and record history,
usually due to retroactive updates, then we need to bite the bullet. One
of the hardest parts of this is educating users on how bitemporal history
works. Most people don’t think of a historical record as something that
changes, let alone of the two dimensions of record and actual history.

Append-only History

In a simple world a history is append-only. If communication is perfect
and instantaneous than all new information is learned immediately by every
interested actor. We can then just treat history as something we add to as
new events occur in the world.

Bitemporal history is a way of coming to terms that communication is
neither perfect nor instantaneous. Actual history is no longer
append-only, we go back and make retroactive changes. However record
history itself is append only. We don’t change what we thought we
knew about Sally’s salary on Feb 25. We just append the later knowledge we
gained. By layering an append-only record history over the actual history, we
allow the actual history to be modified while creating a reliable history
of its modifications.

Consequences of Retroactive Changes

Bitemporal history is a mechanism that allows us to track how a value
changes, and it can be extremely helpful to be able ask
sally.salaryAt(actualDate, recordDate). But retroactive
changes do more than just adjust the historical record. As the expert
says: “People assume that time is a strict progression of cause to effect,
but actually from a non-linear, non-subjective viewpoint – it’s
more like a big ball of wibbly wobbly timey wimey stuff.” If we’ve paid Sally $6000 when we should have paid her
$6400, then we need to make it right. At the very least that means getting
more in a later paycheck, but it may also lead to other consequences.
Maybe the higher payment means she should have crossed some important
threshold a month earlier, maybe there are tax implications.

Bitemporal history alone isn’t enough to figure out these dependent
effects are, that demands a set of additional mechanisms, which are beyond
the scope of this pattern. One measure is to create a parallel model,
which captures the state of the world as it should have been with the
correct salary, and use this to figure out the compensating changes.
Bitemporal history can be useful element
for these kinds of measures, but only unravels part of that big ball.

Perspectives for Record Time

My example above for record time uses dates to capture our changing
understanding of actual history. But the way we capture record history can
be more involved than that.

To make everything easier to follow above, I sampled the history on the
payroll dates. But a better representation of a history is to use date
ranges, Here’s a table to cover 2021

record dates	actual dates	salary
Jan 1 – Mar 14	Jan 1 – Dec 31	6000
Mar 15 – Apr 4	Jan 1 – Feb 14	6000
Mar 15 – Apr 4	Feb 15 – Dec 31	6500
Apr 5 – Dec 31	Jan 1 – Feb 14	6000
Apr 5 – Dec 31	Feb 15 – Dec 31	6400

We can think of Sally’s salary being recorded with a combination of two
keys, the actual key (a date range) and the record key (also a date
range). But our notion of record key can be more complicated than that.

One obvious case is that different agents can have different record
histories. This is clearly the case for Sally, it took time to get
messages from the HR department to the Payroll department, so the record
times for those modifications to actual history will differ between the
two.

department	record dates	actual dates	salary
HR	Jan 1 – Feb 14	Jan 1 – Dec 31	6000
HR	Feb 15 – Dec 31	Jan 1 – Feb 14	6000
HR	Feb 15 – Dec 31	Feb 15 – Dec 31	6400
Payroll	Jan 1 – Mar 14	Jan 1 – Dec 31	6000
Payroll	Mar 15 – Apr 4	Jan 1 – Feb 14	6000
Payroll	Mar 15 – Apr 4	Feb 15 – Dec 31	6500
Payroll	Apr 5 – Dec 31	Jan 1 – Feb 14	6000
Payroll	Apr 5 – Dec 31	Feb 15 – Dec 31	6400

Anything that can record a history will have its own record
timestamps for when it learns information. Depending on that data we may
say that an enterprise will choose a certain agent to be the defining
agent for recording certain kinds of data. But agents will cross lines of
authority – however big the company, it won’t change the recording dates of
the tax authorities it deals with. A lot of effort goes into sorting out
problems caused by different agents learning the same facts at different
times.

We can generalize what’s happening here by combining the notion of the
department and record date range into a single concept of a perspective.
Thus we’d say something like “according to HR’s perspective on Feb 25,
Sally’s salary was $6400”. In a table form, we might visualize it like
this.

perspective	actual dates	salary
HR, Jan 1 – Feb 14	Jan 1 – Dec 31	6000
HR, Feb 15 – Dec 31	Jan 1 – Feb 14	6000
HR, Feb 15 – Dec 31	Feb 15 – Dec 31	6400
Payroll, Jan 1 – Mar 14	Jan 1 – Dec 31	6000
Payroll, Mar 15 – Apr 4	Jan 1 – Feb 14	6000
Payroll, Mar 15 – Apr 4	Feb 15 – Dec 31	6500
Payroll, Apr 5 – Dec 31	Jan 1 – Feb 14	6000
Payroll, Apr 5 – Dec 31	Feb 15 – Dec 31	6400

What does this collapse into a single perspective concept give us? It
allows us to think about what other perspectives might be. One example is
to consider alternative perspectives. We could create a perspective where
we remove individual raises (such as Sally’s on Feb 15) and give
every employee a salary raise of 10% on March 1st. That would lead to a new
record-time dimension for Sally’s salary.

perspective	actual dates	salary
real world	Jan 1 – Feb 14	6000
real world	Feb 15 – Dec 31	6400
with global raise	Jan 1 – Feb 28	6000
with global-raise	Mar 1 – Dec 31	6600

This generalization of the notion of record time says that we can layer
multiple perspectives over an actual history, using essentially the same
mechanism to reason about retroactive changes and alternative histories.

Putting many perspective dimensions over a history isn’t something
that’s widely useful, even compared to bitemporal history. But I find it a
helpful way to think about these kinds of situations: reasoning about
alternative scenarios, either historically, or in the future.

Storing and Processing Bitemporal Histories

Adding history to data increases complexity. In a bitemporal world I
need two date parameters to access Sally’s salary –
sally.salaryAt('2021-02-25', '2021-03-25'). We can simplify
access by defaults, if we treat the default for record time as today, then
processing that only needs current record time can ignore the bitemporal
complications.

Simplifying access, however, doesn’t necessarily simplify storage. If
any client needs bitemporal data, we have to store it somehow. While there
are some databases that have built-in support for for some level of
temporality, they are relatively niche. And wisely, folks tend to be
extra-wary of niche technologies when it comes to long lived data.

Given that, often the best way is to come up with our own scheme. There
are two broad approaches.

The first is to use a bitemporal data structure: encoding the necessary date
information into the data structure used to store the data. This could
work by using nested date range objects, or a pair of start/end dates in a
relational table.

record start	record end	actual start	actual end	salary
Jan 1	Mar 14	Jan 1	Dec 31	6000
Mar 15	Apr 4	Jan 1	Feb 14	6000
Mar 15	Apr 4	Feb 15	Dec 31	6500
Apr 5	Dec 31	Jan 1	Feb 14	6000
Apr 5	Dec 31	Feb 15	Dec 31	6400

This allows access to all the bitemporal history, but is awkward to
update and query – although that can be made easier by making a library
handle access to bitemporal information.

The alternative is to use event
sourcing. Here we don’t store the state of Sally’s salary as our
primary store, instead we store all the changes as events. Such events
might look like this

record date	actual date	action	value
Jan 1	Jan 1	sally.salary	6000
Mar 15	Feb 15	sally.salary	6500
Apr 5	Feb 15	sally.salary	6400

Pay attention to the fact that for if events need to support bitemporal
history, they need to be bitemporal themselves. This means each event
needs an actual date (or time) for when the event occurred in the world,
and a record date (or time) for when we learned about it.

Storing the events is conceptually more straightforward, but requires
more processing to answer a query. However much that processing can cached
by building a snapshot of the application’s state. So if most users of
this data only required current actual history, then we could build a data
structure that only supports actual history, populate it from
the events, and keep it up to date as new events trickle in. Those users
who wanted bitemporal data could create a more complex structure and
populate it from the same events, but their complexity wouldn’t make
things harder for those who wanted the simpler model. (And if some people
wanted to look at actual history on a different record date, they could
use almost all the same code for working with current actual history.)

---

Enterprises are moving full steam to the public cloud unencumbered by what is happening in the economy. If anything, volatility due to Covid has raised the importance of cloud benefits and the prospect of flexibility and scalability has further accelerated this movement. Enterprises no longer view public cloud as merely Infrastructure as a Service (IaaS). Instead, they are looking for a highly integrated enterprise platform.

Data is the heart of the matter. In particular, data warehousing has emerged as the backbone of cloud data strategies. Every CIO must now solve the challenge of re-platforming their workloads from on-prem systems to cloud native ones.

Curiously, instead of new vendors sweeping the floor with their legacy counterparts, a very different dynamic is emerging. For example, Snowflake, who positioned itself as the #1 cloud migrator recently had to admit that it isn’t that easy, after all. 

On the other hand, an incumbent boldly proclaimed that vendor lock-in will keep them in business for a very long time. And their surging stock price suggests that analysts may see it the same way.

What’s going on here? Why is there not more turnover in the database market if it is of such high value? The answer is as simple as disheartening: moving between databases is a cruelly difficult business. Fueled by overly optimistic advertising, many simply underestimate the challenge. 

Database migrations have abysmal track record

The industry has long grappled with the problem of migrating between databases. Not surprisingly, enterprises suffer when vendor lock-in holds them back from tapping new technology and innovation. Talk to any enterprise IT leader, and you learn that a considerable amount of time and money is spent continually on trying to keep up with new technology developments and moving from old to new.

More concretely, any proposal to move workloads on a mid-range data warehouse system of one vendor to another is an eye-watering experience. The typical estimates are upward of 3 years of time with a price tag of at least $20m. And that’s just the opening gambit. Once the migration is underway, things very often spiral out of control: $20m becomes $50m, and 3 years becomes 5 years. Finally, a new CIO just puts an end to it altogether to stop the bleeding.

For each successful migration, there are about 6-10 failed ones. Even the successful ones are not always convincing. Often, a successful migration is little more than a partial offloading where the legacy system continues to run complex workloads that were just too difficult to move. The result is an ever-increasing fragmentation of the IT landscape within the enterprise and with it increasing technical debt.

Application rewrite is the true problem

Fueled by grand statements made by vendors of database migration tools, customers often fall into the trap of thinking that transferring the content from the old to the new system is the problem. It is a critical part, no question. But it’s just a small fraction of the cost.

The lion’s share of the pain—and the cost—comes from rewriting applications. Applications need to be adjusted to make them work with the database. Vendor-specific SQL, tools and utilities have found their way into every crevice of the enterprise. Even inside 3rd party systems, custom SQL was a critical element of accelerating the business in the past. However, what once was a competitive advantage has turned into a liability.

None of this should come as a surprise. So why then the high failure rate? Shouldn’t we, as an industry, know better by now? First, until recently there simply wasn’t an alternative, so we just soldiered on. Second, the problem is extremely treacherous: the first 80% of the migration are often a walk in the park and trick folks into believing they are about done. It’s the last 20% that kill migrations.

The difficulty of the 20% comes from the tight interplay between application and database content. Any compromise during content transfer (lack of data types, lack of support of Stored Procedures, etc.) exponentially increases the difficulty of the application rewrite. Staging a migration to convert content first, and applications independently afterward is a recipe for failure.

Bespoke solutions are non-solutions

Today, the industry implements bespoke solutions. This is fancy-talk for cutting corners. Yet, we’ve been doing this so long that it has become folklore. Ask any IT leader and they will associate database migrations with failed projects that overran their budget and were way behind schedule by the time they got killed off.

However, as database technology becomes more commoditized, there is less and less room for these bespoke solutions. The enterprise that doesn’t have to resort to a bespoke solution, can run faster, and outperform its competitors. The pace of tech adoption then truly becomes a competitive advantage.

Time for a new paradigm

Much effort is being devoted to speed up migrations: automatic code conversion is an area of intense development. However, instead of speeding up something known to be ultimately insufficient, a new paradigm is in order. As Henry Ford said: “If I had asked people what they wanted, they would have said ‘faster horses’”.

Similarly, the database industry needs to break out of the cycle of old approaches that haven’t been delivered. The problem isn’t new: other areas of IT had exactly the same challenge. Practically every one of them has been redefined in the past 20 years by virtualization. From server virtualization to storage and network, the concept of virtualization has eviscerated migration challenges across the board.

With the industry-wide need to migrate database systems to the cloud, virtualization—the disintermediating of applications and database systems—is the logical next step. While still a young discipline, the first products are already on the market with more under active development. The future where applications can move seamlessly between databases has just begun.

GetX Listview :

In previous tutorial we have seen the implementation of fetching data using GetX library in this blog we will be going through the process of populating data in flutter app using GetX listview.

We have used provider which will go through the widget tree until it will find the value, controller and data binding in order to fetch the data and populate to listview.

We can populate data dynamically using this listview widget follow this GetX tutorial till the end for more detailed information.

 

 

 

pubspec.yaml :

Add get dependency in the pubspec.yaml to implement GetX Listview.

dependencies:
  flutter:
    sdk: flutter
  get: ^4.3.4

 

provider.dart :

Specify the provider class which is extending the GetConnect and implement the getUser() async method.Where we are specifying the API inside this method.

And based on the response we will be populating the Listview, if there is any error then display a error message.

 

import 'package:get/get.dart';

class Provider extends GetConnect

  Future<List<dynamic>> getUser() async
    final response = await get('https://randomuser.me/api/?results=10');
    if(response.status.hasError)
      return Future.error(response.statusText!);
     else 
      return response.body['results'];
    
  

 

datacontroller.dart :

Specify the data controller class which is extending GetX controller.Inside which we are specifying onInit() and onClose().

Using which we can fetch the data and populate.

 

import 'package:flutter_fetch_data_getx/provider/provider.dart';
import 'package:get/get.dart';

class DataController extends GetxController with StateMixin<List<dynamic>>

  @override
  void onInit() 
    super.onInit();
    Provider().getUser().then((value) 
      change(value, status: RxStatus.success());
    ,onError: (error)
      change(null,status: RxStatus.error(error.toString()));
    );
  

  @override
  void onClose() 
    // TODO: implement onClose
    super.onClose();
  

 

databinding.dart :

Initialize the controllers inside the data binding.Using which we can access the data through out the app.

 

import 'package:flutter_fetch_data_getx/controller/datacontroller.dart';
import 'package:get/get.dart';

class DataBinding extends Bindings
  @override
  void dependencies() 
    Get.lazyPut(() => DataController());
  

 

route.dart :

Specify the routes i.e., the screens to be navigated are declared in this screen.Here we can also specify the bindings associated with the screen.

Add the pages as required in this routes class.

 

import 'package:flutter_fetch_data_getx/bindings/databinding.dart';
import 'package:flutter_fetch_data_getx/data.dart';
import 'package:get/get.dart';

class Routes

  static final routes = [

    GetPage(
      name: '/data',
      page: () => Data(),
      binding: DataBinding(),
    ),


  ];

 

main.dart :

Declare the GetX library specify the initial routes and get pages.

 

import 'package:flutter/material.dart';
import 'package:flutter_fetch_data_getx/routes/route.dart';
import 'package:get/get.dart';

void main()
  runApp(MyApp());


class MyApp extends StatelessWidget 
  const MyApp(Key? key) : super(key: key);

  @override
  Widget build(BuildContext context) 
    return GetMaterialApp(
      initialRoute: '/data',
      getPages: Routes.routes
    );
  

 

data.dart :

Populate the data onto the screen using this class to implement GetX Listview. Here we are extending the GetView and specify the data controller.

 

import 'package:flutter/material.dart';
import 'package:flutter_fetch_data_getx/controller/datacontroller.dart';
import 'package:get/get.dart';

class Data extends GetView<DataController> 
  @override
  Widget build(BuildContext context) 
    return Scaffold(
      appBar: AppBar(
        title: Text('GetX Network Call'),
      ),
      body: controller.obx(
          (data) => Center(
            child: ListView.builder(
                itemCount: data!.length,
                itemBuilder: (BuildContext context, int index)
              return Card(
                child: Column(
                  children: [
                    ListTile(
                      title: Text(data[index]['name']['first']),
                      subtitle: Text(data[index]['name']['last']),
                      leading: CircleAvatar(
                        backgroundImage: NetworkImage(
                          data[index]['picture']['thumbnail']
                        ),
                      ),

                    )
                  ],
                ),
              );
            )
          )
      ),
    );
  

Output :

This screen depicts the usage GetX Listview usage.

 

If you have any query’s on this tutorial on GetX Listview do let us know in the comment section below.If you like this tutorial do like, share us for more interesting content.

 

Upcloud is a finland based cloud service provider that offers hosting solutions as cheap as $5 per month. Upcloud hosting is one of the best alternatives to DigitalOcean, Linode, AWS, Azure, Skysilk, Interserver & Vultr. In the fast paced world, it is very important that your website does not take much time to load even on the devices with less internet speed. As such, it is crucial for the webmasters to deploy their websites on the servers nearest to the locations from where their visitors mostly visit apart from choosing the fast hosting solution.

I remember the old days when I used to open five to six web pages from the search results and continued with the one which loaded faster(exceptions exist). That was the time when faster was the winner. Much of that has not been changed yet. Even now with fast internet speed, we have witnessed to see the growth of video content. As such, many websites use embed video and social media content, loads of Javascript libraries and what not to make it very heavy. So, as of today not only a better server can help you get the speed but optimization can. In this post, I will review Upcloud hosting service and also tell you how you can optimize your website and server for better performance.

Upcloud Hosting Features: Review Highlights

Secure and Reliable

Upcloud offers hosting service that is secure and is capable of limiting the traffic by IP address or Port with a firewall. It offers scheduled simple and flexible backup options that make it highly reliable.

100% Uptime

Uptime is very important for any project you may have. You can use any uptime monitoring tool such as Screpy to monitor the uptime. Upcloud gives its users 100% Uptime SLA and a 50x payback for any downtime over 5 minutes.

24/7 Customer Support

Customer support is very crucial for determining the strength of a hosting company. Upcloud is among those that offer you quick response for your queries. Their customer support is very reliable. There is live chat option enabled on their website as well. So, when you put your query, a support person is immediately assigned to the conversation to assist you with your questions. Upcloud uses intercom live chat to assist its customers.

Highly Scalable

Most of the web owners switch from shared hosting or low potential hosting to a cloud VPS hosting when they have scalable plan. For all those enthusiasts, Upcloud is really like a boon. Their cloud infrastructure assures you of the best performance and uptime. Considering the scalability, Upcloud is one of the best hosting alternatives you can think of.

Flexible Hosting

Upcloud is definitely a flexible hosting solution. You can at any time opt to resize your server which includes downgrading and upgrading of your existing server. In order to resize your existing server, you first need to shutdown your server which is otherwise than deletion and takes only 2-3 minutes.

You can either choose from the standard resizing plans or opt to customize your plan under flexible plan option where you can manually choose the CPU, Memory, RAM or Storage.

Cost Effective Hosting Solution

Upcloud charges their clients on the hour basis for the servers. As such, they have complete flexibility on resizing the server or testing a new server without having to worry about the high cost.

2-months free migration period

With upcloud, you don’t have to worry about the extra costs of migration from a different cloud service provider. Upcloud charges you no service costs for the migration, for a 2 month free migration period. However, this offer is available for the entities the infrastructure of whose costs not less than $500 per month on Upcloud.

Designed for the developers

With Upcloud it is easy to use the control panel and API that let users code more reliably.

Performance with MaxIOPS

MaxIOPS block storage technology leaves the competition behind and doesn’t throttle performance depending on how much you pay. It is far better than SSD storages. It gives you high performance and reliability. With the cloud technology, you can create your server within a minute. With MaxIOPS, you can also move one MaxIOPS block storage device to an another cloud server. Even it is very flexible as you can customize the amount of storage space you need.

Upcloud Object Storage

The hosting platform also offers fast to deploy and easy to manage Object Storage. One can use it deliver the content worldwide. With Upcloud Object storage you get upto 1 TB of Storage and 2TB of Transfer for the monthly cost of $20.

Upcloud UI/Interface

Upcloud website has a modern interface that is easy to understand and faster to navigate. Once you open up your dashboard, you get to know everything very clearly. Wherever there is any strong term used, there is knowledgebase link there from where you can get to know a lot of information about that. Any new user can easily deploy a new server, resize, create automated backups, add team members

Upcloud Backups

With Upcloud, you can create backups by paying additional costs for your server. These automated backups can be purchased both at the time of new server deployment and at any time after the server is created. There are three backup plans one can opt for viz. Week Plan, Month Plan, and Year plan.

Week Plan	Month Plan	Year Plan
Daily Backups for 7 Days	Daily Backups for 7 days	Daily Backups for 7 days
No Weekly backup	Weekly Backups for 4 Weeks	Weekly Backups for 4 Weeks
No Monthly Backup	No Monthly Backup	Monthly Backups for 1 Year
Price on top of Plan: 20%	Price on top of Plan: 40%	Price on top of Plan: 60%
$1 per month for $5 per month server Plan (price vary based on server selected)	$2 per month for $5 per month server Plan (price vary based on server selected)	$3 per month for $5 per month server Plan (price vary based on server selected)

Upcloud Advanced Firewall

Upcloud offers an advanced firewall that limits server traffic. It ensures advanced protection from various hacking attempts. To make use of a firewall, you need to add incoming and outgoing traffic rules. Like automatic backups, a Firewall also costs you excess cost to your normal server cost. The firewall works based on rules on a first match basis from top to bottom.

Server Tags

Upcloud allows you to organize your servers. As such, you can give a tag to any of your existing servers. With the help of these tags, you can segregate your various project and even make use of them while giving permissions to members inside your workspace.

Add Team Members

Like Linode, DigitalOcean, and many other hosting platforms, Upcloud too allows you to add trusted members to whom you can give various permissions. You have control over whether to give them access to all or any selected property for servers, private networks, storage, and tags.

Server Statistics

You can see the stats for your server inside your server overview dashboard. It shows you statistics graph for 24 hours, 1 week, 1 month and last 1 year.

How to Deploy a new server on Upcloud

Deploying a new server on Upcloud is really easy. Follow these simple steps with me:

1. Sign in or Create a new account
2. Once you have finished creating your account after adding your right billing information you will be asked to at least add $10 to claim the promotion credits. You can also be asked to validate your details via email so keep a track on your email id. (Note: Some users claim that their server is stopped without their notice and they also give bad reviews on the online forums for the same. But this usually happens because they miss an important email from upcloud that is often sent to validate your information)
3. When you finally have been credited with the promotion credits you have not less than $35 in your balance depending on your initial addition. Now that is enough to help you start deploying a server.
4. Now go to your upcloud dashboard: https://hub.upcloud.com/ where you will be redirected to servers section by default where you can find ‘deploy’ button. You can also go to “https://hub.upcloud.com/deploy” directly to deploy a new server on Upcloud.
5. You will be redirected to deployment page which is further divided into multiple sections viz. Location, Plan, Storage, Automatic Backups, Operating System, Optionals and SSH Keys. From the next points, lets discuss about each of these sections.
6. Location: Here you need to basically choose the location of your server. You can choose to select from where your traffic comes or you expect to come. It is also possible that you don’t find the location as desired. In such case, you can opt to choose the nearest location. For say, if your traffic mostly comes from India, you can choose Singapore location. But it is always your choice, it is not mandatory to do so. However, it matters in terms of performance.
7. Plan: You need to choose the plan for your server. Either you can opt for simple plan or you can choose a flexible plan that lets you customize features such as CPU cores and memory as per your requirements. If you are buying server for a new website, you can go with $5 per month plan or $10 if it is a big website with lots of fuctions and for which performance is crucial. You can resize your plans later if you find any additional requirements.
8. Storage: In this section you can choose amount of storage capacity you require for your project. However, in Simple plan you already opt storage, CPU, RAM in your plan, so you can’t customize the storage in this section if you have opted for any simple plan above. As such you can only choose where to go with VirtIO, IDE or SCSI where the default VirtIO is best based on performance tests.By clicking on the name, you can also rename your storage device.
9. Automated Backups: In this section you get an option to enable automated backups. It is definitely a great feature to avoid any data loss or to avoid any unexpected loss of data. Upcloud gives you three backup options to choose from viz. Week plan, Month Plan & Year Plan. In week plan, you have technically 1 week backup always with you and in monthly plan you have last month data backed up. In the last yearly plan, you have last 12 months data backed up. However, you should choose to enable this option only if you want to or need to as it will increase your cost.
10. Operating System: The next section asks to choose the desired operating system for your new server. You can opt for an OS based on your website requirement. For example, if you need to host a wordpress website you can go with Ubuntu Server, Plesk or Windows Server for an ASP.net website. By default, you select the latest version of any operating system whereas you can change it to older version by clicking on the change version dropdown below them. It is always better to choose the latest or default version for new website. However, if you want to move then you can match the versions.
11. Optionals: The next section allow you to choose whether to add a public IPv6 address to your server and also enables you to edit metadata with respect to your server.
12. At the last, it asks you to put SSH keys which is optional. You can also change the hostname and description before you deploy your very first new server on Upcloud.

How To Resize an Existing Upcloud Server

Once you have deployed the server and you want to upgrade or degrade your existing server you can do that by resizing your server. To resize your server you first need to go to your Upcloud Dashboard and click on the existing server.

On the overview tab, you can see the Configuration section where you can find the specifications of your existing server. Below that, there is resize button to manipulate the server specifications.

Once you click that button it shows you the below window. To resize your server, you will first need to shut down your server first. Once your server is shutdown, the resize section containing various plans will become active and you can choose the plan of your choice.

You can also customize new server under flexible plan.

Resizing will take a couple of minutes. You will get a notification and also an email updating you about the new server up-gradation/degradation status. So, this is how you can easily resize your existing server on Upcloud within a matter of minutes.

Upcloud Pricing

The simple pricing plans of Upcloud hosting are listed below:

CPU	RAM/Memory	Storage	Transfer	Pricing
1	1 GB	25 GB	1 TB	$5 /mo
1	2 GB	50 GB	2 TB	$10 /mo
2	4 GB	80 GB	4 TB	$20 /mo
4	8 GB	160 GB	5 TB	$40 /mo
6	16 GB	320 GB	6 TB	$80 /mo
8	32 GB	640 GB	7 TB	$160 /mo
12	48 GB	960 GB	9TB	$240 /mo
16	64 GB	1280 GB	10 TB	$320 /mo
20	96 GB	1920 GB	12 TB	$480 /mo
20	128 GB	2048 GB	24 TB	$640 /mo

Is Upcloud better than DIgitalOcean and Linode?

Competitively, Upcloud can be compared with DigitalOcean and Linode in terms of performance and infrastructure. Upcloud doesn’t disappoint you if you move from any of the two.

Is Upcloud worth the money?

Considering many of the great features such as hourly payment, easy to deploy and manage, scalability, flexibility and performance, one can say that Upcloud hosting is a great value for money.

Conclusion

Without a single doubt, Upcloud is one of the fastest and reliable hosting service providers as of today. With the state of the art technology and cloud infrastructure, it is able to suffice the need of its users who give importance to performance. Upcloud lets you quickly deploy servers, resize them anytime, take automatic backups, put a firewall, manage members for your workspace, and all that with an intuitive layout. With ready-to-scale and highly flexible services, Upcloud let’s control your cost at your staging time and quickly manipulates as you fly. Conclusively, you can concentrate more on your projects.