Pakistan's First Oracle Blog

Who wants to mention in their resume that one of their operation task is to tag the cloud resources? Well I did and mentioned that one of the tools I used for that purpose was Tag Editor. Interviewer was surprised to learn that there was such a thing in AWS which allowed tagging multiple resource at once. I got the job due to this most under-appreciated and largely unknown service.

Tagging is boring but essential. As cloud matures, tagging is fast becoming an integral part of it. In the environments I manage, most of tagging management is automated but there is still a requirement at times for manual bulk tagging and that's where Tag Editor comes very handy. Besides of bulk tagging Tag Editor enables you to search for the resources that you want to tag, and then manage tags for the resources in your search results.

There are various other tools available from AWS to ensure tag compliance and management but the reason why I like Tag Editor most is its ease of use and a single pane of window to search resources by tag keys, tag values, region or resource types. It's not as glamorous as AWS Monitron, AWS Proton or AWS Fargate but as useful as any other service is.

In our environment, if its not tagged then its not allowed in the cloud. Tag Editor addresses the basics of being in cloud. Get it right, and you are well on your way to well-architected cloud infrastructure.

Recently Pradeep Parmer at AWS had a blog post about transitioning from DBA to DBI or in other words from database administrator to database innovator. I wonder what exactly is the difference here as any DBA worth his or her salt is an innovator in itself.

Administering a database is not about sleepily issuing backup commands or in terms of Cloud managed databases clicking here and there. Database administration has evolved over time just like other IT roles and is totally different what it was few years back. 

Regardless of the database engine you use, you have to have a breadth of knowledge about operating systems, networking, automation, scripting, on top of database concepts. With managed database services in cloud like AWS RDS or GCP Cloud SQL or Big Query many of the skills have become outdated but new ones have sprung up. That has always  been the case with DBA field. 

Taking the example of Oracle; what we were doing in Oracle 8i became obsolete in Oracle 11g and Oracle 19c  is a totally different beast. Oracle Exadata, RAC, various types of DR services, fusion middleware are in itself a new ballgame with every version. 

Even with managed database services, the role of DBA has become more involved in terms of migrations and then optimizing what's running within the databases from stopping the database costs going through the roof.

So the point here is that DBAs have always been innovators. They have always been trying to find out new ways to automate the management and healing of their databases. They always are under the pressure to eke out last possible optimization out of their system and that's still the case even if those databases are supposedly managed by cloud providers. 

With purpose built databases which are addressed different use case for different database technology the role of DBA has only become more relevant as they have to evolve to address all this graph, in-memory, and other cool nifty types of databases.

We have always been innovators my friend. 

 In simple words, a general Database Engine is a big clunky piece of software with features for all the use cases, and its up to you to choose which features to use. Whereas in a purpose built database, you get a lean, specific database which is only suitable for the feature you want.

For instance, AWS offers 15 purpose-built database engines including relational, key-value, document, in-memory, graph, time series, and ledger databases. GCP also provides multiple databases types like Spanner, BigQuery etc. 

But the thing is that the one-size-fits-all monolithic databases aren't going anywhere. They are here to stay. A medium to large organization has way too many requirements and features to be used and having one database for every use case increases the footprint and cost. For every production database, there is a dev, test, and QA database so the foot print keeps increasing.

So the thing is that though having purpose built database notion is great it's not going to throw monilithic database out of the window. It just provides another option for the organization and they could just have a managed service for purpose built database for a specialized use case but for a general database requirement for OLTP and data warehouse, monilithic is still the way.

 Even though AWS RDS (relational database service) is a managed service which means that you won't have to worry about upgrades, patches and other tidbits, you still have the option of manually triggering the upgrade at time of your choice.

Upgrading an Oracle database is quite critical not only for the database itself but more importantly for the dependent applications. It's very important to try out any upgrade on RDS on a test representative system before hand to iron out any wrinkles and check the timings and any other potential issues. 

There are 5 important steps before upgrading Oracle on AWS RDS you can take to make this process more risk-free, speedy, and reliable:

1. Check Invalid objects such as procedures, functions, packages etc in your database.
2. Make a list of the objects which are still invalid and if possible delete them to remove clutter.
3. Disable and remove audit logs if they are stored in database
4. Convert dbms_jobs Jobs and other stuff to dbms_scheduler
5. Take Snapshot of your production database right before you upgrade to speed up the upgrade process as then during upgrade only delta snapshot will be taken

Richly asynchronous server-less applications can be built by using AWS step functions. Choice State in AWS Step Functions is the newest feature which was long awaited.

In simply words, we define steps and their transitions and call it State Machine as a whole. In order to define this state machine, we use Amazon States Language (ASL). ASL is a JSON-based structured language that defines state machines and collections of states that can perform work (Task states), determines which state to transition to next (Choice state), and stops execution on error (Fail state). 

So if the requirement is to add a branching logic like if-then-else or case statement in our state transition, then Choice state comes handy. The choice state introduces various new operators into the ASL and the sky is now limit with the possibilities. Operators for choice state include comparison operators like Is Null, IsString etc, Existence operators like Ispresent, glob wildcards where you match some string and also variable string comparison.

Choice State enables developers to simplify existing definitions or add dynamic behavior within state machine definitions. This makes it easier to orchestrate multiple AWS services to accomplish tasks. Modelling complex workflows with extended logic is now possible with this new feature.

Now one hopes that AWS introduces doing it all graphically instead of dabbling into ASL.

Here is quick easy set of instructions as how to read docker inspect output:

First you run the command:

docker inspect <image id> or <container id>

and then it outputs in JSON format. Your normally are interested in what exactly is in this docker image which you have just pulled from web or inherited in your new job. 

Now copy this JSON output and put it in VSCode or any of online JSON editor of your choice. For a quick glance, look at the node "ContainerConfig." This node tells you what exactly was run within the temporary container which was used to build this image such as CMD, EntryPoint etc. 

In addition to the above, following is the description of all the important bits of information found in Inspect command output:

• ID: It's unique identifier of the image.
• Parent: A link to the identifier of the parent image of this image. 
• Container: The temporary container created when the image was built.
• ContainerConfig: Contains what happened in that temporary container.
• DockerVersion: Version of Docker used to create the image

Virtual Size: Image size in bytes.

I hope that helps.

 I just published my very first tutorial video on youtube which lists down a quick introduction to AWS BOTO3 with a step by step walkthrough of a simple program. Please feel free to subscribe to my channel. Thanks. You can find video here.

 Following is the checklist while troubleshooting workload/application errors in Kubernetes:

1- First check how many nodes are there

2- What namespaces are present

3- In which namespace , the faulty application is

4- Now check faulty app belongs to which deployment

5- Now check which replicaset (if any) is party of that deployment

6- Then check which pods are part of that replicaset

7- Then check which services are part of that namespace

8- Then check which service correspond to the deployment where our faulty application is 

9- Then make sure label selectors in deployment to pod template are correct

10- Then ensure label selector in service to deployment are correct.

11- Then check that servicename if referred in any deployment is correct. For example, webserver pod is referring to database host (which will be the servicename of database) in env of pod template is correct.

12- Then check that ports are correct in clusterIP or nodeport services. 

13- Check if the status of pod is running

14- check logs of pods and containers

I hope that helps and feel free to add any step or thought in the comments. Thanks.