Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In our project, we were using Amazon Cognito for authentication, authorization and user management. It’s very easy to use, basically, you just need to create a user pool, identity pool, and users (everything you can “click” from AWS console).
I will not go into the details, you can read how to do this step by step from official AWS docs.
The adoption of serverless functions is reaching record levels within enterprise organizations. Interestingly, given the growing adoption and interest, many monitoring solutions silo performance of the code executed in these environments, or provide just basic metrics about the execution. To understand the performance of applications, I want to know what bottlenecks exist, where time is being spent, and the current state of each system involved in fulfilling a request. While metrics, logs, and segmented stack traces are helpful, a more cohesive performance story is still the most useful way to understand an application, and should be achievable using existing technologies.
In this post, I’ll explore how to achieve a cohesive performance story using OpenTracing to instrument an Express app running in a local container, and a function running on Lambda. For visualizations and analysis, I’ll use LightStep [x]PM for this example, although you can choose another OpenTracing backend like Jaeger.
These days, the Marc Andreessen “Software is Eating the World” maxim seems universally accepted — or at least, it is popular enough that if a tech person mentions it at a cocktail party, those who know nothing about software nod their head in agreement and the tech people all groan.
It’s basically understood that in our Internet-enabled world, technology equals software, even though the reality is more nuanced. And even the cloud, the grand enabler of the latest software wave, is itself being eaten alive by the software movement it has spawned, with cloud-native ecosystems such as Docker and Kubernetes devouring the value of verticalized cloud providers and offering a portable software experience across any infrastructure substrate, spanning architectures, providers, and form factors. Boy, it’s a good time to be in software!
Fission is an open source, Kubernetes-native serverless functions framework with support for public, private, and hybrid clouds. Support for Kubernetes enables the portability of Fission functions with the ability to create once and deploy anywhere for consistency in code development. This accelerates your software delivery pipeline without sacrificing quality.
Fission is made up of three core concepts:
Keeping in mind the growing multi-cloud trend, developers should start working with more than one provider. However, this can mean leaving your comfort zone, and not everyone likes the idea of doing that. Recently, I’ve done this and would like to share my experiences with you. I believe they are useful, regardless of whatever cloud platform you are using/are going to use.
We have a legacy serverless application hosted on Azure Functions. There were some issues with it:
I use AWS CodeCommit to hold the work-in-progress articles for this blog. It's free, it's private, and it's not living on a disk drive in my house.
To access my repositories, I use SSH private key authentication. Unlike GitHub, CodeCommit doesn't just let you attach a public key to a repository. Instead, you associate a public key with a user token, and must use that user token to access the repository. That's not too onerous, because you can put the token in your .ssh/config:
Kubernetes and containers have been revelatory for application development, but they’re not the complete solutions enterprises might like them to be. Yes, both address organizations’ long-held desires for agility, efficiency, and accelerated application development. However, there remain some missing elements that may hold back Kubernetes’ explosive adoption rate for mission-critical workloads in the modern enterprise.
All of these elements can be traced back to the fact that neither Kubernetes nor containers feature native storage. Although historically seen as an afterthought by developers, storage remains an essential component for enterprise applications, especially in the age of containers.
Every software system is built to serve a specific purpose and to achieve clear objectives for a business. Everything from the design of a system to the infrastructure supporting it needs to be geared towards those collective objectives. In many ways, the way a system is designed mimics how buildings are structured: integrity and functionality are two inseparable elements that make both a structure and a system perform the best way possible to realize their intention.
Amazon Web Services (AWS) serves as the perfect foundation for a well-designed system, but in order for AWS to serve its purpose as a cloud platform designed to provide the optimal cost-effective and secure environment for its customers, it needs to be well-architected.
If you're reading this, chances are that you do not want to use jx cluster create to create a new cluster that will host Jenkins X. That is OK, and even welcome. That likely means that you are already experienced with Kubernetes and that you already have applications running in Kubernetes. That's a sign of maturity and your desire to add Jenkins X to the mix of whichever applications you are already running there. After all, it would be silly to create a new cluster for each set of applications.
However, using an existing Kubernetes cluster is risky. Some people assume that it will be easy to create a cluster from scratch. "We're so awesome that we don't need tools like Rancher to create a cluster for us. We'll do it with kubeadm." Then, after a lot of sweat, we announce that the cluster is operational, only to discover that there is no StorageClass or that networking does not work. So, if you assembled your own cluster and you want to use Jenkins X inside it, you need to ask yourself whether that cluster is set up correctly. Does it have everything we need? Does it comply with standards, or did you tweak it to meet your corporate restrictions? Did you choose to remove StorageClass because all your applications are stateless? Were you forced by your security department to restrict communication between Namespaces? Is the Kubernetes version too old? We can answer those and many other questions by running compliance tests.
For the digital era, the cloud has proved to be a huge blessing. It enables storing large amounts of information — photos, videos, music, messages, etc. with a limited budget. With the dawn of the Internet, backing up data became much easier by storing it on the server rather than a hard drive. Also, data can be accessed using Internet-enabled devices. It is fascinating to know that the birth of the Internet has made it possible to squirrel away a huge amount of data without buying extra storage devices like memory sticks or hard drives. Recently, with technological advancements, we have seen Google Docs and Gmail taking the place of Microsoft Word and Outlook Express. But, the raised concerned is data security in the cloud. Have you ever asked yourself the question: is your data secure on the Internet?
We have seen too many cases of data hacking in the past. In 2011, Sony’s PlayStation Network carried all the news channels by storm for its news of data hacking. A huge amount of user information was compromised. Also, in September 2018, we came across news of Facebook security breach exposing more than 50 million user accounts. This was the largest breach in the last 14 years of the company’s history, affecting millions of lives by compromising their personal information.
Microsoft Azure, which holds second-highest market share in the cloud computing domain is threatening to grab top honors in near future. To a great extent, the credit for this success is also due, to the ease with Microsoft Azure can be accessed to carry out computing. Azure Portal contributes greatly to this vertical. In this article, we will be exploring how Azure Portal makes it easy to bring all Azure's services under one umbrella.
Before we dive deeper and understand Azure Portal any further, here is a sneak peek into the pointers this article focuses on:
This is part 4 of a 6 part series, introducing Microsoft Azure for Spring developers. I couldn't have put this together without input from Microsoft's Asir Vedamuthu Selvasingh, Yitao Dong, Bruno Borges, Brian Benz, and Theresa Nguyen. You can find the code for this series on Github. You can also learn more about Microsoft Azure in my Spring Tips (@SpringTipsLive) installment, Bootiful Azure.
Here are all the installments:
In the '90s, server software came in boxes containing floppies and CDs that required expert knowledge and hours of setup before it was production-ready. Nowadays, launching server application and infrastructure software is just a few clicks away in all of the major cloud vendors’ marketplaces. However, some fundamental platform challenges around standardization still need to be solved, and Kubernetes seems to be the likely solution to overcome these issues.
In the early days of computing, software and hardware were tightly coupled. Applications written for a specific computer would not work on machines from other vendors. Third-party application providers, also known as ISVs (Independent Software Vendors), that wanted to target multiple platforms typically had to rewrite or modify large chunks of their software to address differences in the underlying hardware. The arrival of cross-platform operating systems and languages changed all of this, allowing ISVs to write their software to a single set of APIs and offloading the responsibility of porting to different hardware platforms to the operating system vendor.
Running Docker in production has quickly become the norm. Cloud hosting providers like AWS, GCE and Azure realized that this is what organizations need. Services like EKS and ECS from Amazon offer a completely managed environment for your Docker containers to run on. Through this article, we’ll take a closer look to one of them, Amazon ECS, which is Amazon Elastic Container Service. We are going to describe what AWS ECS is, its functions, and its importance in the current market.
“AWS ECS is a fully-managed, scalable and production-ready platform for running containers.”
If you don’t know what any of this means, then the rest of the article is going to help you with that. Suffice it to, say, "fully-managed" implies you don’t have to pay any third-party software vendor to run your containerized application. "Scalable" means you don’t have to worry, ahead of time, about resource utilization. AWS Cloud will make resources, like CPU, memory and storage, available to you, on demand.
You might be familiar with Azure Functions, a capability in Azure to run small pieces of code. Microsoft launched Azure Functions in early 2016 as a preview, and it became generally available mid-November of 2016. Now almost two years later Microsoft made Azure Functions 2.0 available. In this blog post, we take a lap around this second version of Azure Functions. Here you get a look at new UI changes, templates, development, DevOps, and future roadmap.
The new version of Azure Functions is available with an SLA of 99.95% – meaning that functions running on a consumption plan will run 99.95% of the time after the trigger is successfully fired, or on an app service plan, the compute will be available 99.95% of the time. Furthermore, you can benefit from:
You are experiencing more traffic, and your IT team is complaining that it’s becoming more difficult to allocate the resources to meet that increased demand. It’s become harder and more expensive to keep up with your data storage. You know you are at a point where you need a disaster recovery plan, but that is going to be costly for sure.
All of these are familiar issues SMEs and startups face as they begin to grow their operations. And in-house infrastructure solutions can "break the bank" for those who expect to grow larger and yet remain Agile.
There are a lot of guides on “Docker for Java developers,” but most of them do not take care of small and efficient Docker images.
I have combined many resources on how to make a simple and fast Docker image containing any Spring Boot-like application.
In my previous article from this series, we looked into the details that determine how your integration becomes the key to transforming your customer experience.
It started with laying out the process of how I've approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint.