Learn Something

When developing Software as a Service (SaaS) products, an important consideration is the isolation model used to restrict cross-tenant access. Many legacy applications utilise a siloed architecture that physically or virtually separates resources. However, a pooled isolation model offers greater flexibility and agility when it comes to developing and deploying your application. By leveraging serverless AWS services, an agile but secure architecture can be achieved.

When developing applications, it’s common practice to run the same application in multiple environments. Usually a development environment for general volatile changes, a test environment for integration testing and quality assurance, and a production environment for a final release.  With multiple environments all using the same infrastructure, they require consistent replication. A common challenge is that over time each environment can drift from the standard and become too unique to accurately replicate. An example of drift is resource IAM permissions being changed in one environment, but the change isn’t documented and replicated in the other environments upon deployment.

When modernising legacy systems, a key issue is figuring out how to migrate your existing data into a database that has been remade from the ground up. Rewriting outdated applications from scratch usually means a brand-new schema that can look unrecognisable next to the old one. Transferring the existing dataset into your new system is a challenge that requires rigorous planning, development, and testing.

It wasn’t all that long ago that the question of ‘security’ was considered a major impediment to the adoption of cloud computing services. Happily, the ‘theoretical’ security problems which arise from having your data on someone else’s computer, haven’t been borne out in any practical sense. That’s why cloud computing, including platform-as-a-service from Amazon Web Services and many other providers, has become the defacto way of resourcing companies from the smallest to the biggest.

When it comes to the cloud, the biggest name is Amazon Web Services (AWS) which commands more market share than the next four competitors combined. Not bad for a bookseller! So, when you’re looking at migrating infrastructure to the cloud, and there are many good reasons to do just that, AWS is probably one of the best available options.

Those who are considering migration need to know just exactly what is involved. There are challenges and issues which must be noted and handled to ensure a smooth transition to either a complete ‘in the cloud’ setup, or the more common hybrid arrangement, where some infrastructure remains on-premise and some is moved to AWS.

Don’t be fooled by the deceptive ease with which you can get started on the Amazon Web Services cloud. While it is certainly true that you can get stuck in with nothing more than a credit card and a vague idea of what you’re after, it pays to start with sound foundations so that as your needs grow and evolve (as they inevitably do – just about everyone who tries AWS very quickly becomes a big fan of it’s low-cost, high-value services), you don’t end up with a horrendous tangle.

If you are running servers or workloads in the AWS cloud, you’re probably aware of the Amazon Web Services Well Architected framework. First introduced by AWS in 2015, this framework is widely used by AWS Certified Architects to create a planned and structured infrastructure which will meet your needs today and into the future.

Consisting of five pillars, the Well-Architected framework sets the scene for having in place cloud foundations that complies with best practices. In this article, we dig a little deeper into it and consider the core pillars of AWS Foundations, and why you really should be using them in your environment.

That’s right, you need to call time on your relationship with the office server. If it helps, you can promise one another you’ll just be friends, and relegate the server to a minor role on the side. Or go hard, pull the pin completely and shut it down for good.

Admit it, you’ve probably had a few technology love affairs over the years. Was it the iPhone? That shiny new convertible laptop? We might not have been there, but did you brag about impressive specifications just after spending tens of thousands on the new server?

Maybe so, but times have changed and it just doesn’t measure up any longer.

With the whole world apparently going cloud crazy, you might get the idea that you’re missing out (and the chances are, if your technology systems are long in the tooth, you are). Check out these five signs which show your business is ready to take the leap…and reap the rewards.

In the good old days, software development involved the ‘arms-length’ interaction of business analysts, IT operations, programmers and testers. But the thing about the good old days is this: they weren’t all that good. Software routinely took ages to produce and then didn’t work very well. That, fundamentally, is what has given rise to the emergence of the new way of developing software called DevOps.

The word itself provides a very good clue into what it is. A contraction of Development and Operations, DevOps pulls together all the disciplines required to produce functional software. DevOps is about multidisciplinary teams working closely together, which is quite distinct from the tried, tested, and not-so-great idea of functionally separated organisations.