Archive for the ‘cloud computing’ Category

Technology updates for mobile apps

June 25th, 2021 by Ishan Geeganage

The iOS operating system for Apple devices, and the Android operating system for Samsung and many other brands of mobile devices, are constantly being updated to provide tools to allow developers to implement new features supported by new hardware, and to improve the performance and security of apps on iTunes and the Google Play store.

This article provides an overview of some recent enhancements to the operating systems and developer environments, which will flow through to app features and opportunities for your future mobile apps.

Wearables

Both Apple and Google have recently enhanced the libraries and opportunities available for developers to provide richer experiences on wearables, such as the Galaxy watch and the Apple iWatch. This is in response to the increase in proliferation of wearables (watches, rings, fitbits etc) and the internet of things, whereby devices such as TVs, motor vehicles, gas meters, watering systems and the like are internet enabled.

Now 3rd party apps are able to add tiles to the watches bringing to the front of the user experience information from your app, where that was previously only available to proprietary apps. In addition, 3rd party apps have more access to notifications, including the ability to break through “do not disturb” features. However, we need to bear in mind that, particularly in the case of Apple, the review process is very stringent and Apple will be guarding the use of these features very carefully to ensure that they are only used in the most appropriate circumstances.

App Store Promotion

Apple, which lags behind Android with regard to the ease with which apps can be promoted, have announced that they are improving the Apple Store Connect to allow app owners to test images used within the app store, to select those that attract the most downloads, and promote events related to their apps also from within the app store.

Apple are now supporting promotion codes to be used by app purchasers in order for app owners to run promotions to provide a discount or free app usage for a period of time. However, Apple and Google continue to have differences in the way promotions run (Google being more flexible) which ultimately constrains the marketing of apps particularly when you want to be “fair” to all segments of the market. Google Play Store’s promotion code and discount functionality offers more flexibility than iTunes, and in fact Apple will no longer allow you to build in your own promotion code facility, even when all payment for the app is taking place via the Apple payment system.

Apple do like to promote their own ecosystem at the expense of others – not surprising really! Another example of this is if you allow users to sign in to your app using a 3rd party authentication mechanism such as a Google account or Facebook account, you must also allow them to use their Apple ID to login. This means that you require custom code in your cross platform app to remove the Apple ID login for Android users, and you need to support Apple ID login even if you aren’t expecting many users to want to login this way.

Google are also planning improvements to the Google Play Store with regard to promoting apps for wearables, and making it easier for people with wearables to install apps on their watch or other devices.

Privacy

Both Apple and Google are focusing on enforcing privacy for users of apps. We discuss the privacy changes on the Apple platform in another blog post about the launch of iOS version 14.5. Google’s Android version 12 (still in beta) is also giving privacy a boost in what it calls “Private by Design”. A few of the changes include Bluetooth scanning for nearby devices no longer requiring location services to be switched on, and where location services are required, allowing the user to only report an “approximate location”. In addition, users will be able to permit an app to take an action “this time only” instead of for all time.

Concurrency Supported Natively

Apple have released an updated version of Swift – the language in which developers now build iOS Apps – which allows concurrency (the app executing more than one command simultaneously) within the language. This is a big win for future app performance, for example, depending on your app concurrency could allow the user interface to continue to present new information to the user, while their previously submitted information is being processed. Kotlin – the language of choice for native Android development – has supported concurrency and threading for some time.

Compiling iOS Apps in the Cloud

Another important step forward in the iOS app development ecosystem is the announcement of XCode Cloud. Whilst still in beta, Xcode Cloud will facilitate continuous integration and continuous delivery for building apps and automatically send notifications to testers. This will be possible when XCode Cloud is used in conjunction with a git source code repository. It will also allow developers to compile the app in the cloud, rather than taking minutes / hours to compile on the developer’s computer, effectively preventing them from doing any work while that is happening.

Both Apple and Google are improving developer tooling to help developers test parts of their application through better emulators e.g. the new CarPlay simulator for Mac, and the new virtual heart rate sensor in the Google emulator.

Better support for Augmented Reality (‘AR’)

Google announced in March an overhaul of their Google Maps functionality, including the improvement of their Live View Augmented Reality feature which allows you to point your phone at the surrounding buildings (in large cities that have been mapped) or within buildings (such as inside airports) in order to figure out where you are, and get live on screen directions pointing you to where you need to go.

Apple has recently launched the RealityKit 2 library, in order to allow the creation of high-quality, photo-realistic 3D models of real-world objects in minutes by taking photos shot on iPhone, iPad, or DSLR and transforming them into 3D models optimized for AR. Google also has made recent improvements to the app developer environment for easier implementation of AR within Android apps.

AR is clearly an area where both platforms are keen to press forward and provide richer user experiences, and not just for gaming!

Foldables

With the release of foldable mobile devices such as the Galaxy Z Fold 2, the Android development libraries have been enhanced to allow developers to customise the user interface in different ways for foldable devices, and mobile devices with larger screen sizes.

All the above changes are welcome enhancements, but many of the features rely on users updating their phone operating systems or hardware. Still it is good to keep the above improvements in mind when considering functionality for your new app, or upgrades to an existing app.

If you would like to discuss your app idea, don’t hesitate to get in touch.

Facebooktwitterredditpinterestlinkedinmailby feather

Cloud Middleware for APIs Supporting Multiple Goals

October 23rd, 2020 by Heather Maloney

There’s no getting around it – businesses are increasingly using many different apps to handle specific tasks. Accounting, marketing, order fulfillment, sales, project management, the list goes on. Each application chosen by a business performs important tasks very well, but adds to the complexity of the business operations, particularly when information needs to be shared between the applications. Manually moving data between the applications takes precious time and is mundane work, and therefore runs the risk of not being done or being done poorly (with errors) or late.

cloud-based middleware for integrating applications

For many years, we have assisted our clients to solve these problems by implementing integrations between their websites / web applications / SaaS products and other business applications. The upfront cost of the integration has paid for itself many times over in time saving for the business, however, when the 3rd party application changes functionality or changes the API exposed to the public to allow the integration, then the integration can break and requiring rework.

Enudge email and SMS marketing app, designed and built by Contactpoint in 2006, has been enhanced to integrate with many different applications over the years. Enudge is presently integrated with Pipedrive (a deal management app), Gmail, Outlook, Xero and Salesforce, making it easy for people using these apps to send contact data to and from their Enudge account. These integrations can be costly to build and maintain, and there is always another app on our list, waiting for our team to integrate with!

We are always looking for ways to help our clients grow using technology, and doing that in ways that are cost effective, robust, secure and scalable.

A better solution to Integration.
The maturity of cloud-based middleware services that support application integration has led us to recently explore how these can be employed for our clients, to solve the problems I’ve described and support the following 3 Use Cases / business goals:

  1. Automating routine business tasks to save time e.g. creating an invoice in your online accounting system whenever a sale is made in your online store, adding a new customer of your online store into your email marketing platform.
  2. Ensuring integrations keep running, and are easy to maintain.
  3. Enabling other applications to integrate with your application in a cost-effective way, providing greater marketing reach for your application, and making it easier for your customers to use your solution.

Cloud-based middleware services, such as Zapier and Automate.io, act like the glue between applications or a marketplace where any app can connect with any app.

For the 1st goal – automating routine tasks – the ability to shift data around is significantly easier when your apps are supported by a middleware service. As a very simple example, you can set up the task of adding a new customer (in your online store) into your marketing platform, which then sends out a welcome email and ensures future email campaigns are sent to that new customer as well, all without you needing to do anything.

For the 2nd goal – easy to maintain integrations – the applications who enabled the middleware platform to integrate with their application are motivated to ensure the integration keeps running, and will ensure that it does, or give you plenty of warning that you need to update your integration.

For the 3rd goal – making it easy for others to integrate with your application, and all the advantages that brings – the middleware solves the huge problem of how to have enough resources (time & money) to enable integration with the vast array of applications that logically have a need to integrate with your application. Enudge, for example, should logically integrate with every CRM and ecommerce platform, as well as every lead generation solution. Using a middleware means that the effort to implement the integration can be carried out once, and support potentially thousands of applications. In addition, there will be automations required by our clients that can be supported by the middleware service, that we would never have thought of and therefore never supported. For example, what if an Enudge user needs to print name tags for every customer who indicated they would attend an event by clicking on the “I will attend” link in their Enudge Action Responder email campaign, and that name tag is created by a special name tag app? If the name tag app is available in the middleware service, receiving contact names, and Enudge has a trigger of “Clicked Yes” exposed in the middleware service, then suddenly integrating the two applications is available, without either application needing to know about the other.

It is perhaps the “marketplace” nature of the cloud-based middleware that is the most exciting aspect. It gives you the ability to quickly integrate two or more apps together to mimic your workflow, saving you time and money, and freeing up your time to get on with your core business.

So what is the downside; there’s always a catch, right?
Well, you need to have and pay for the account with the middleware service. The cost usually depends on the number of integrations you have in place, and how many times these are used on a monthly basis. These services aren’t prohibitively expensive compared to building and maintaining individual integrations yourself. It is not hard to calculate the return on investment provided by a service, based on the time it saves you.

The other issue you need to address is whether the business apps you have selected are available on your choice of middleware service.

Ideas worth Exploring?
If there are aspects of your business operations that are impacting on your time, feel free to get in touch so that we can explore together how they might be cost effectively solved using integrations.

If you are using Enudge and would like to integrate your account with another application, please get in touch. We are currently building integrations into the Zapier platform for Enudge, preparing for public launch, and would love to talk with you about being part of the beta testing phase.

Facebooktwitterredditpinterestlinkedinmailby feather

Embracing Serverless Cloud Technology

July 23rd, 2020 by Pavithra Kameswaran

In this article I will describe how serverless cloud architecture for a modern digital application provides Contactpoint clients with the opportunity for quicker time to market, less dependence of a particular technology and lower hosting costs.

When we say that a software application is running in the cloud, we mean that all the resources and services that the application utilises are hosted on the Internet. The internet is a mass combination of connected computing servers processing some 98,038Gb worth of traffic per second (at the time of writing!).

Accessing an application, and data it creates, which is hosted in the cloud simply requires a device (PC, tablet, mobile phone …) that a browser runs on, and a connection to the internet. As an example, all of the business software that Contactpoint use is running in the cloud, so that we no longer need to have those applications stored on physical servers in our office. This has meant that moving to everyone working from home during the COVID-19 pandemic has been relatively easy. We simply took our devices home, and continued to have access to all the resources we need, including our telephone system.

So what’s the big deal about serverless cloud?

The term ‘serverless’ cloud refers to technology architecture where the developers of a software application do not need to concern themselves with the underlying servers upon which the technology is operating. It is yet a further level of abstraction, compared to provisioning private servers in the cloud, or virtual private servers that are then allocated to particular applications and maintained with regard to software versions, security updates, disk space, performance and physical hardware that needs to be replaced over time.

Our most recent serverless technology implementation for a client’s SaaS product (soon to be launched) comprises a back-end using AWS Amplify, AWS Appsync, AWS DynamoDB and AWS Lambda – more about these components in a moment. As stated by AWS (Amazon Web Services; one of the most popular and comprehensive cloud computing platforms) using a serverless architecture allows you to “build and run applications and services without thinking about servers. It eliminates infrastructure management tasks such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning … everything required to run and scale your application with high availability is handled for you.”

It is still vital that as developers we plan, architect and provision resources appropriate for the application being developed, but the serverless architecture reduces much of the issues and workload (both upfront and long-term) associated with managing servers in the cloud. Even more importantly for our clients, serverless architecture allows you to only pay for those services that are used by your application and only when those services are actually used. Depending on the payment option selected by you, payment can be down to the millisecond of processing power used by your application.

The competition between the main cloud providers – AWS, Microsoft Azure and Google Cloud – is fierce as they are vying for share of market, and our clients are often able to secure generous incentives to build on a particular platform such as free services for a year.

It is important to note that a serverless application has a very different architecture compared to a traditional application, in order to take advantage of the benefits of serverless. As developers we need to give much more weight to considering how often each function within an application will be invoked, how long the process will run for, and how much data will be transferred, as these will all have an effect on the costs of running the serverless application as it scales, as well as the performance of the application. Serverless application development also requires the use of components provided by the cloud provider in order to achieve the ability for the application to scale – underneath the covers these components take care of provisioning more physical servers and computing power to meet the demand of the application.

For our client’s SaaS product, choosing serverless architecture is the right choice as their app is destined for use by millions of people across the globe, but will start small. Using serverless means that they will only pay for the small amount of usage upfront, but the application will automatically scale as demand grows.

A brief summary of the main components used for the backend of our client’s application are as follows:

AWS Amplify is a framework and toolset within which mobile apps and web apps can be built. It facilitates the development of UI-driven, highly scalable applications and provides access to a large number of AWS cloud services.

AWS Appsync allows us to write GraphQL APIs in the cloud. GraphQL is a trending, flexible and a fast API query language. The choice between a REST API and GraphQL API, their respective advantages and trade-offs, is a topic for another blog! With directives such as @auth and @model, Appsync generates queries, mutations and resolvers for us, which we can then customise to the application requirements. It also provisions tables in the DynamoDB automatically, and both these put together, provides significant time saving in the app development. It helps developers focus more on core functionality of the app, business logic and front end.

AWS DynamoDB is a NOSQL database which continuously backs up the data, and automatically scales as required. Being a NOSQL database provides great performance for fast return of data.

AWS Lambda provides us with a platform to write microservices that will compute as required and only incur costs per computation. With the right usage, Lambda is very effective due to its nature of continuous scalability and zero administration required.

When should I choose serverless architecture for my application?

The general factors to consider when choosing serverless architecture are:

  1. Quick and continuous scalability – auto-scaling is an important attribute of serverless architecture. If your app is targeting a large user base e.g. the general public, then the number of your users, and their demands for resources, can grow very quickly. For example, a new online health magazine could grow to a million readers, but might start very small. If you were to allocate resources and services to cater for a million users right at the beginning, you would have lots of idle resources and need to maintain those as well as cover the cost until the readership grew. Using architecture that isn’t auto-scaling would involve much effort by the hardware, software and security teams to keep us as you grow. Auto-scaling solves these problems.
  2. Effective Cost Management – as mentioned above, building and provisioning resources with a million readers in mind right from the beginning could incur huge costs until the app makes it to a million readers. Instead, by developing serverless we will use resources and services as needed by the n number of users currently, and will scale up as the number of readers grow to a million (or more). Thereby, we will incur costs for the infrastructure only as it is used and presumably paid for by the users.
  3. High Availability – AWS components like Amplify and Appsync provide offline data access and conflict resolved synchronisation when back online. The databases and storage also tout high availability of data since distribution of servers in the cloud has facilitated almost zero downtime and 24/7 availability. This is why many organisations are migrating legacy applications to the cloud, and converting them to serverless applications.
  4. Low Maintenance – AWS databases such as DynamoDB and storage systems such as AWS S3 are so low in maintenance that we can almost term them as zero maintenance. AWS claims that DynamoDB requires absolutely no maintenance at all. Once setup properly, it can keep operating continually, scaling as required, and performing as designed and intended. Even the relational databases provided by AWS, such AWS Aurora, require very less maintenance (updates and patching) when compared to other non-serverless databases.
  5. Performance – last but not least, one of the most important factors for all applications is performance. We can have an online health magazine app that has the content and potential to become the most popular app ever, but if it cannot deliver content quickly for a million or more readers, it is bound to fail. By performance, we are referring to the speed of data retrieval, data submission, loading of the user interface (where that is part of the server-side application) and the speed of functions that process the data and business rules / programming logic of the application.

What languages does serverless architecture support?

When building an app within a serverless infrastructure such as the AWS platform described above, you still need to choose the programming language within which you will write the application that lives on the device of your end user, or is accessed via the cloud by the end user. This programming language then needs to be able to interact with the components above. AWS provides many options in this regard including NodeJS, Java, Go, PowerShell, JavaScript, C# and .Net framework, C++, Ruby and Python.

For our most recent application we chose NodeJS for the backend code, and ReactNative combined with NativeBase for the mobile apps. This choice allows for similar languages to be used across the frontend and backend of the SaaS product, providing for a simpler implementation, and easier application maintenance over time. However, some components of the AWS environment support Javascript, and Javascript libraries and frameworks better than others – like all cloud platforms, they are ever expanding and improving the functionality that they make available to developers to speed up development. We needed to switch choices of libraries several times to resolve unexpected issues with parts of our app due to less support for ReactNative compared to native mobile application languages (Java for Android and Swift for Apple).

Depending on the way your application is constructed, the serverless architecture also makes it easier for you to mix code implemented in different languages, allowing you to use best of breed for each function within your application.

Should I move my legacy or web application to serverless?

As I mentioned above, many organisations are moving their applications which were built and deployed on a dedicated server (either on-premise or in the cloud) to serverless architecture to gain one or more of the benefits. Before deciding to move an application to the cloud, you will need to consider the effort involved – you will only achieve some of the available benefits if you simply “lift and shift” your existing application. To fully benefit from the move, your application will need to be re-built in the new architecture. For this reason, organisations often put off a transition until their application is sufficiently in need of a re-build before making the move.

As a developer, I look forward to working on applications which help our clients grow, through the amazing scale possible via serverless cloud architecture.

Facebooktwitterredditpinterestlinkedinmailby feather

Contactpoint Switches Project Management Tools

January 14th, 2020 by Heather Maloney

When Contactpoint started back in 2006, there were no internet-based technologies for meeting a core need of our organisation; that of managing the ad hoc requests from our clients for modifications to their websites, as well as project management of new websites and software development. Consequently we built our own solution, which we named the Contactpoint Client Area – exciting name, I know! – we had no intention of marketing it to anyone :-).

Over the years, regularly updated our client area to keep up with the growing needs of our organisation and our team members. For example, we added kanban boards to help manage workflow as our team grew in size. We expanded it to associate tickets and project tasks to standard process checklists to help with quality control. We added a prospect section to help us keep track of enquiries which then could be easily associated with a new client. Anything we wanted to improve about how we worked could be embodied into our online tool to help us achieve it, and clients also were able to see the details of the work. Needless to say, we revelled in our work on the client area.

As the architect of the client area, I was very proud and, yes, attached to our client area. Not only had it served us well, it also contains 13 years of client history, which is a valuable resource for all sorts of reasons.

Roll forward to 2019, it had become clear that there were now many commercial project management tools with price tags that made them very attractive for SMEs, some of which came with features that we had not had time to build. Our team – a mixture of developers, project co-ordinators, designers, and digital marketers – were needing our work management tool to better support their work practices and workflows.

Over the past 18 months I have reviewed more than 50 project management tools to try and find a solution that had everything our client area included, as well as the better features that we were hoping to take advantage of, so we can focus more on what’s of prime importance to us – our client work – without having to tend to regular updates to meet our ever growing needs or having to compromise on the features that are essential in helping us deliver quality work. Unfortunately I didn’t quite find that; all of them called for compromises. Yes, our client area was full of useful features that were hard to be substituted, but I continued my research until in the end, I zeroed in on Goodday.work – a cloud solution built by an organisation dedicated to producing the best possible work management solution for businesses of all sizes.

We cut over to the new software on the 1st November, 2019. It was a big change for us, and not something we took lightly. Initially we planned to import our historical records, but in the end we took across only current tickets and projects.

Online solutions constantly evolve, so we are confident that the few pieces of functionality we are missing compared to our in-house built solution will be provided in the relatively near future. The benefits we have gained from the new solution are substantial making it easier for us to manage team workflow. One the of biggest benefits is the concept being able to assign a task to the person who is ultimately responsible for its delivery, while being marked as action required by another team member. The tool allows you to view work in lists, table views, kanban views and gantt charts, allowing our different teams (particularly digital marketing compared to software developers) to work in the way that best fits the type of work they are performing, thereby achieving something that was always high on our client area wish list. It also supports tagging, filtering, customised views, and a powerful search facility across all types of information. It also has a great name – nice to think of having a good day at work, everytime you use it. 🙂

We are still only using part of the functionality it offers, and look forward to using more as we continue to discover how it can help us.

The change our clients will see are as follows:

  • Ticket numbers, which had reached over 11,000 in our client area, have been started again from zero in the new system. To help differentiate, we now refer to them as tasks, as this is actually the naming convention used by Goodday.work.
  • While we wait for a more feature-rich client-facing view of the information, we won’t be providing access to the project management tool for our clients. However, it is quicker for us to produce a gantt chart view of a particular project, and predict completion dates.
  • Automated ticket update emails will not be generated to our clients from the solution for the time being. However, as always, we will provide updates by phone or email.
  • It will now be easier for us to quickly determine when a particular piece of work will be able to be completed, with workload easier to view per team member, including scheduled future work.

Because our in-house built client area resides on our own servers, we can keep it indefinitely as a source of the historical records for as long as required.

If you have any questions about the process we undertook to review the extensive list of work management tools, or our transition to the new tool, please don’t hesitate to get in contact.

Facebooktwitterredditpinterestlinkedinmailby feather

Cloud does not equal the Internet

November 13th, 2018 by Heather Maloney

Cloud does not equal the internet
People frequently use the term “cloud” or “in the cloud” to simply mean located on the internet or their private intranet. I’ve done it myself, for the sake of expedience. However, they aren’t the same thing, and it’s important to understand why so that you can wisely choose the internet services you are accessing for your business or in your personal life. For example, cloud hosting is not the same as shared web hosting, for the hosting of your organisation’s website.

The internet is the connection of computers around the globe using TCP/IP protocol to manage the connections, and participating in the sharing of information using the HTTP protocol (the worldwide web).

The term “Cloud” or “Cloud Computing” refers to technology services, usually delivered over the internet, which are characterised by:

  • Distribution of a system (program and its data) across many servers and locations, to provide for greater performance, but still providing up to date and correct data.
  • Automatic provisioning (addition of greater capacity via more CPUs, memory and disk space) to meet minute-by-minute requirements.

Applications embodying cloud computing are often further labelled as SaaS (software as a service), PaaS (platform as a service), IaaS (infrastructure as a service), and other ‘…aaS’ names. These labels draw attention to which part of the abstraction of the technology is controlled by the buyer compared to the service provider. However, not all applications given these labels actually provide the two main characteristics that I am asserting differentiates cloud computing ? distribution across many servers, and automatic provisioning. Instead, software delivered as a service via logging into a web application may in fact be stored on one server, in one location, with one database, and require the service provider to manually procure and set up new servers when usage demands the additional resources.

The characteristics of cloud technology provide advantages and disadvantages which I will discuss in a moment, but let’s first consider the technological challenge cloud technology is trying to solve.

As you can imagine, there’s an awful lot of information contained within Facebook. Millions of users each adding several posts, and making hundreds of comments, on a daily basis, adds up very, very quickly. Not only is there a lot of data being stored and accessed by users of Facebook, people are posting and reading comments from all around the globe; some on their phones while riding on a train, others are sitting at their desktop computer in the back of beyond, and everything in between. No one will use Facebook if it takes more than a few seconds for the content to appear on their screen, and Facebook is used by people all around the globe. Facebook is just one example of an application which handles vast amounts of data and serves vast numbers of people.

To make Facebook possible, as well as other applications like it, the underlying technology has to be distributed across multiple servers and locations – a distributed system. There are numerous technical models used to achieve a distributed system. Below are brief descriptions of just a few of the techniques to give you a feel for the complexities involved.

Techniques

Sharding. A term allowing a single database to be stored across multiple servers by allocating logical portions of the data onto different servers. A very rudimentary example would be determining which server to store the data based on a range of identifiers such as in the case of user accounts the decision could be made to store all data with a user ID between 1 and 100,000 on server 1, between 100,001 and 200,000 on server 2, and so on. The application retrieving the data would send the query to the application server, and then the database server would work out which server to get the data from based on the user ID, get that data and return it back to the user. There are many options for the way that a database may be divided; the right way for a particular application will need to consider the way current data is spread across it’s attributes as well as how future data may grow.

NOSQL. The example given above for sharding described separation of data contained within a relational database; the most common database architecture up until very recently, which as the name suggests relates tables of information to one another by linking IDs. A person’s record in a database may contain an ID to another table storing the details of the school they attend (name, address, phone number etc) – hence being called a relational database. NOSQL or Document Databases have become more popular recently as they can be spread more easily across multiple servers because all the data associated with the person in the sharding example would be stored in one document rather than spread amongst related tables. Document databases often come with functionality built into them to manage distributing documents in the collection across multiple servers.

Caching. Storing data located near to users, providing faster access particularly for commonly used information is referred to as caching. Facebook makes heavy use of memcache to store recently accessed Facebook information in memory, which is much faster to read than from the Facebook MySQL database which is housed on hundreds of thousands of servers. Content Delivery Networks (‘CDN’) are an example of caching of web content to ensure it is closer to your website visitor.

Other concepts such as virtualization, utility computing, and grid computing are also key in the implementation of cloud computing particularly with regard to auto-provisioning of additional computing resources.

Advantages

We have touched on some of the advantages of cloud computing in relation to the problems it is trying to solve. The advantages can be summarised as:

  • Security. A cloud solution must be focused on security in order to have success over the long term, and they usually have significant resources at the ready to keep security up to date, and respond quickly when a new threat arises. Look for:
    • End-to-end encryption which ensures the encryption of all data in-transit across the Internet and stored at-rest in the cloud, with the encryption keys held by you and used to encrypt the data before it leaves your computer.
    • Sophisticated access controls allowing you to set role-based authentication to control what exact data each user can and cannot view, edit or share.
  • Performance. Because there is likely a server nearby to the user, rather than the user’s request needing to travel half way around the world and back, you can expect the speed of cloud systems to be significantly better. Performance is a key factor for organisations with a workforce distributed around the globe.
  • Scale. The ability to distribute an application and/or its data across multiple servers and locations removes or significantly reduces the constraints on how large an application can grow or how many customers it can efficiently serve.
  • Cost. Another key benefit of cloud is that usually someone else is responsible for concerns such as installation of software and purchase of licenses, management of software patches, backups, hardware upgrades and repairs, anti-virus and protecting against malicious attacks, all handled by the provider of cloud computing rather than the organisation requiring the technology. When comparing the cost of cloud and non-cloud you must take into consideration the total cost of ownership of the alternatives. Auto-scaling (also referred to as elastic computing) is a factor in both cost and performance, as it allows systems to scale up (additional costs) when demand increases, and scale back (reduce costs) when demand is low, allowing the owner of the system to only pay for resources when they are required.

Disadvantages

It is important to also be aware of the potentially significant disadvantages of cloud computing:

  • Data ownership / sovereignty. Where is your data really? Who has access to it? Have you read the terms and conditions with respect to the ownership of the data? Can you remove your data permanently, or will it still be accessible by the cloud provider even after your account is closed? Often the owner of the data you place into a cloud computing solution is actually the cloud provider, not you. To help mitigate this issue, some cloud providers are implementing servers in additional countries including Australia, to help organisations to use cloud services without moving their data overseas, but you need to check where your data is stored; often such storage choice will increase the cost of the solution. NB: even if your data starts out being stored in Australia, if the data is owned by a US company, they may be forced to move the data back to the US for scrutiny by American law enforcement agencies – this has already happened in the case of Google in February 2017.
  • Privacy. Facebook has been criticised at the highest levels of American government, and by governments around the world, for the way in which the data it gathers (albeit via their free service) has been used and sold on to 3rd parties. The situation with Facebook and other cloud solutions has been a factor in leading to the new European privacy legislation (GDPR). When you utilise cloud platforms, are you comfortable with manner in which they use the data that you are storing within it (read their terms and conditions)? Can you trust the organisation to abide by their promises?
  • Control. Can you create the functionality you need to support your particular processes, or are you now constrained by the services provided by the cloud platform? Using a cloud service to remove the need to create that service constrains you to the functionality the service offers. The more you depend on a 3rd party service, the less likely you are to be able to innovate in that area of your business on application, which may well slow your organisation down and remove your opportunity to create competitive advantage.
  • Cost. Whilst being able to pay per second for your application using cloud technologies may sound like it is going to reduce your cost, if your application isn’t built to take advantage of cloud technologies, the opposite may occur and your costs can be significantly more than using simpler internet technologies. Cost can also be significantly greater if you use the wrong technology on the wrong cloud provider. For example, whilst the major suppliers of cloud technology usually allow you to run any type of application on their cloud servers, the cost of running those different types may be very different. Running a MS SQL database on Google Cloud is extremely expensive, for example, compared to running it in the Microsoft Azure platform. You need to choose your technology wisely.
  • Skills. Not everyone developing applications is experienced in working on large scale applications, and the implementation of applications using cloud technologies is relatively new, so finding personnel with the required skills can be very challenging.

Whilst I have primarily been discussing cloud computing from the point of view of building an application such as Facebook, cloud computing underpins solutions such as Office365, DropBox and GSuite. These applications allow users all over the world, sometimes the one person in different parts of the world in one day, to access their data – emails and files for example – and programs such as GSuite and Word Online, with great performance, and without the data being [noticeably] out of date, most of the time. Such applications are also increasingly providing users with the capability to collaborate on files e.g. contributing to an online document simultaneously, again while located in different cities and countries.

For such commodity type applications, where easy access from anywhere, across multiple devices, makes business much easier, the decision to sign up for cloud computing may feel like a no-brainer. But you still need to consider the disadvantages discussed above.

In summary, not all internet applications are using cloud computing technologies. Cloud computing is a complex area, utilising multiple strategies aimed at providing up to date information, to mass users all around the world, with great speed. It is important that you way up the advantages and disadvantages of cloud computing for both your commodity technology needs (email, file sharing, file storage, and other operational systems) as well as when developing your own applications.

If you would like to read more:
https://enterprisersproject.com/article/2017/1/three-things-companies-must-know-about-data-sovereignty-when-moving-cloud
Use of Memcache by Facebook: https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf

Facebooktwitterredditpinterestlinkedinmailby feather

Subscribe to our monthly

Contactpoint Email News

Our enews is sent out approximately monthly, and contains information on latest digital technologies, and how these can be used to help your organisation grow.

To subscribe, simply fill in your details below: