Another Shameless Plug: Listen To Me at the 2008 MySQL Conference

Those familiar with my personality (the real-life, much more interesting one) know that I am given to spontaneous speechifying on frequent, mostly inappropriate occasions. As a result, they rarely encourage me to share one of my not-so-humble opinions or to grace them with my pithy, Gibran-esque observations on the nature of the human condition, et al. (For those of you who deign to counter this self-assessment of my wisdom, consider the date of this posting before commenting... ^_^)

Every so often, however, I manage to fool someone into thinking that my pedagogical pontifications are worth listening to and I am thus granted a podium on which to speak and share my wisdom (such as it is). Such an occasion is nigh and I encourage you to come out and support my heretofore unfulfilled dream of having a full room with a rapt audience spellbound by my oratory.

Event: The 2008 MySQL Conference & Expo

Location: Santa Clara, CA

Time: 11:55am through 12:40pm on Tuesday, April 15th

Title (sure to whet any appetite): Increase the Flexibility of MySQL-based SOA Frameworks with a Data Access Layer

The Goods:
While many organizations implementing Service Oriented Architectures (SOAs) are adopting a standards-based approach for development of new application services, few are applying the same methodology to their MySQL database access logic. A tightly coupled, MySQL-specific approach to application service design eliminates the benefits of an SOA strategy and results in an infrastructure that slows application deployment and reduces business logic reuse and flexibility.

In this presentation, Mike Frost, product manager for DataDirect Technologies, will introduce a strategy for separating application logic from MySQL database access logic. The presentation will describe the benefits of a loosely coupled approach for all application and data access logic such as reduced development time, simplified deployment, and increased overall flexibility all within an SOA framework. Frost will introduce and describe the concept of a data access layer based on the emerging Service Data Objects (SDO) specification and Data Access Service (DAS) standard and describe what the future of data access logic will look like for MySQL users within an SOA framework.

Additional Details: See http://en.oreilly.com/mysql2008/public/schedule/detail/2578

If you come, you should know that I accept heckling so long as it is followed with an offer of a craft beer not sold within the state of North Carolina - barleywines are my favorite though anything strong that I can fit into my suitcase for the flight back will be graciously accepted. Oh, and don't forget to leave me your business card so that I know who to credit for the soothing of my bruised ego.



craft+beer barleywine MySQL DAS Data+Access shameless+plug Data+Access+Layer SDO SOA speaking+opportunity

Shameless Plug: Vote for (and attend) our TechEd Developer Bof Session

I'm a propeller head - or at least, I used to be one until I traded in my cap for a marketeer's (sic) fez. My techie colleagues have been mostly forgiving of my decision to "sell out" on my former role as a technical support engineer. They have mercifully opted to forgo making references to cliches such as, "I'm not in marketing, I work for a living!" when I ask them how their jobs are going. Still, I know that with my new title, I am less likely to be engaged in the kind of cool water-cooler-type conversations that take place when smart people are taking a break. This unintended consequence of my professional transition from technical geek to technically meek is the reason why I think my presence generates a Seinfeldian "Hello Frosty" reaction whenever I insert myself unceremoniously into such a conversation. I understand where you're coming from: "It's not personal, it's just technical stuff." Just like teens who want nothing to do with their parents, techies want to talk tech with other techies - not with marketing techie wannabes. Inside, however, my inner geek is crying out for respect: "Wait, I was just about to crack a joke that involves a C-shell command on AIX..."

This segueway brings me (somewhat awkwardly, I'll admit) to my role as Shameless Promoter Of Things That Benefit My Employer (a role that comes with the fez rental). Microsoft is allowing people to vote on the topics that will be used for several BoFs (Birds-of-a-Feather sessions, if you're still working on that propeller hat) that will be held at the Microsoft TechEd North America 2008 Developers conference and frankly, we'd like for you to vote for ours.

To vote, go to https://www.msteched.com/dev/voting.aspx. Be sure to scroll about halfway down the list until you will see our entry, Making Sense of All: Heterogeneous Data Access on the .NET Framework 3.5 with an appropriate checkbox, which we'd like for you to check before you submit your selections (I can't assume everyone knows how to vote since the Florida Election Debacle of 2000). More information on the topic, if you're really not going to click above and vote:

In this BoF, we’ll peel back the layers on data access from the .NET platform. We’ll look at the common problems facing today’s applications with a particular emphasis on applications in a multi-faceted, heterogeneous application environment. With all the options now available, including the Data Access Application Blocks, LINQ, Entity Framework and vanilla ADO.NET which is the one for you? Come armed with your questions, ideas and burning issues and we can promise a lively discussion!

If our topic is among the most popular topics voted on, then my esteemed, suitably credentialed, and technically astute colleague Jonathan Bruce will be there to run the show and keep things technically interesting for the smart folks. And if that isn't incentive enough to vote for this and attend, then consider that I might even make it which means that should you show up, you will have a chance to crack an inside joke that relies on geek humor and watch me struggle to get it and try to fit in.

I can guarantee that feeling smug about your tech cred will never feel so good. :)



ADO.NET Jonathan+Bruce Microsofte shameless+plug TechEd

The Server Consolidation Bottleneck

It would be unoriginal for me to submit some sort of apology for the delay between my posts, so I won't offer one. I'm unsure who would care if I neglected to include one anyhow. ^_^

One of the subjects that I have been doing a lot of business research into of late is one of the current IT industry darlings, virtualization. I have a lot of personal and professional interest in learning more on this topic because its impact on how traditional proprietary software companies license their software and because the flexibility and efficiency opportunities that it presents businesses with a significant IT infrastructure.

Like a lot of new technologies, I think there is a gap between the promise of virtualization and the reality of what can be delivered with the current state of the technology. One key example of this gap is the best-articulated business value of virtualization, server consolidation. I recently attended a seminar held locally by VMware where the typical server consolidation ratio for VMware customers was cited as being between 8 and 12 to 1 with some customers achieving a 30 to 1 server consolidation ratio. A 30 to 1, 12 to 1, or even 8 to 1 consolidation in server hardware is remarkable to consider in any case, and would likely get the attention of anyone seeking to reduce the acquisition, deployment, support, power, cooling, and maintenance costs of servers within an IT organization.

So what's the gap here? Basically, that degree of server consolidation assumes that the applications running on the guest machines at most, use the network infrequently or not at all. A recent Wall Street Journal article (Real Virtualization Battle Looms, 2/26/2008) highlighted the "communications bottleneck between server systems that has made it impractical to use virtualization for some of the most demanding applications, such as large databases". In essence, this says that forcing applications requiring significant use of the network to share the network I/O resources of a single server with other operating systems and applications isn't practical. The WSJ article does note that there are some organizations looking at solving the problem of managing network I/O for virtualized environments, but at the same time, if an organization has many applications already running near capacity on a robust hardware configurations, it seems unlikely that virtualization alone will offer them much in the way of a consolidation benefit since increasing network bandwidth isn't easy or cheap.

I do think that the future of virtualization is bright and offers a great deal of promise for the future of IT organizations of all shapes and sizes. Until the practical challenges of consolidating network I/O-heavy applications to a significant enough degree to experience real cost savings is solved, however, the full scope of virtualization's server consolidation benefits will remain untapped.




virtualization server+consolidation VMware application+performance network+efficiency

Becoming a Data Connectivity Geek: Step 1 of 12

"Gee Mike, how can I become as wise about data connectivity as you?"

The above question is proof that although a question may be easy to ask, the answer may not be simple (nor the questioner sane in this case). My professional career started without even cursory knowledge of what a driver was, how relational databases worked, or even how to program in something more modern than FORTRAN (not dating myself as much as hinting that my college career was somewhat atypical for someone in my position). Since that time I have become "sufficiently proficient" in the subject of data connectivity to get myself into trouble, but not quite good enough to get myself out - sort of an anti-Macgyver in that regard.

Anyway, the purpose of this post is to share with you the secret of how I managed to acquire the thimbleful of lore that I have to date: listening to people smarter than myself. Thankfully for me, I haven't had to look far for overqualified individuals at my place of employment - it's like looking for a tall tree in a forest of redwoods. The great news is that these resident geniuses are actually more interested in going forth and helping others who grapple with the weighty questions involving data connectivity than they are in trying to give me the "Dick and Jane" version of every new concept that comes along.

You can meet these Superstars of Standards-Based Database Access APIs at DataDirect's Architect Tutorials at one of the following dates and locations:

Thursday, October 4th | St. Louis, MO - Hilton Frontenac
Thursday, October 11th | Toronto, ON - Westin Harbour Castle
Tuesday, October 16th | Irvine, CA - Hyatt Regency

This year's theme is, "Successful Strategies for SOA Enablement & Data Connectivity," which sounds much more useful and technical than "See Spot Program 'Hello World' In FORTRAN". If my personal recommendation amounts to anything - attend and don't forget to bring a warm thinking cap.


SOA software+architect data+access database data+connectivity geek+tutorials Macgyver

SSIS + data connectivity = read my article

Consider this the first of what I hope will be many shameless plugs of my more "formal" writing. Admittedly the subject isn't as ODBC-related as this blog subject suggests that it should be, but it does touch on an application that a lot of organizations are using - Microsoft SQL Server Integration Services. If you or a colleague are using or are planning to use SSIS to connect with non-SQL Server data sources, let me modestly recommend that you peruse my article as a valuable source of wisdom on the subject. :)

Now that I have reached my limit of reflexive back-patting for the week, I will cease further attempts to cajole you into reading my article but do drop in a comment tell me what you think about the article if you do read it.

SSIS Microsoft data+access sql+server

Assimilated: All Your Mac Are Belong To Us

The picture to the right is what I anticipate I will look like in a couple of weeks (minus the hair, the braces, and the youth). I'm pretty sure I will shed similar tears of joy once a box like that arrives after 6 years of hemming and hawing. That's right, the Mac that I have talked about buying for years (but never quite got up the guts to pull the trigger on) is finally on order.

I will admit to being seduced by the siren call of my Macphile friends to join the ranks of people who love their computers rather than eternally battle them. Furthermore, I freely acknowledge the power that the Apple marketing machine has had at convincing me that I will be cooler, more hip, etc. etc. if I can smugly tell people, "My other computer is a Mac." Still, it took time, the right set of circumstances, and an acknowledgment that I no longer play video games quite as earnestly as I once did for me to come around to the idea that it was nigh time for me to act, rather than to continue simply uttering comments that began with, "One of these days..." To the credit of Apple's marketing, though, I think watching the umpteenth edition of "Mac vs. PC" ads and realizing that rather than wanting to be the nerdy PC guy (even if he is a resident expert at everything), I wanted to be the "stars in a movie with Bruce Willis" guy. :)

When I was young, Macs were seen as primarily the domain of educators, illustrators, and whimsical dreamers who liked to play with "toy" computers. Macs didn't seem as "real" or as macho as the ubiquitous 386, 486, and Pentium monstrosities that pervaded college dorm rooms, sprouted innumerable plugs to multiple peripherals, required disks and disks of software and hardware drivers, and demanded a fair bit of technical savvy to use well. Slowly, over time, Macs went from seeming uncool and way too niche to be respectable to now bestowing upon the purchaser a measure of chic due to the physical design and coolness owning to the "Arty the Smarty" self-confidence that it takes to buy one when most people don't.

So what changed? For one, I don't think that Mac suffered from the surging popularity and image of one of its much younger siblings, the iPod. I also think that as the value of a personal computer transitioned from "tool for playing games" to "tool used to write documents and balance checkbooks" to "tool used to browse the Internet" the distinctions and barriers to Mac ownership by the less-fanatic masses (like me), became fuzzier and disappeared. Of course, when OS X came out, the biggest barrier for me melted away - The Geek Factor. No more can a Mac be called a toy - not when it runs on a Unix operating system. My desire for something new to tinker around with and explore will be redirected from finding ways around the headaches of why my browser keeps crashing (and then asking me if I want to report the issue - as though it hadn't already happened 20 times) to learning all of the neat touches of using the Mac OS.

My MacBook Pro is still on order and it will likely arrive just in time for my vacation. A perfect opportunity, really, because I will have all sorts of time to poke around with it while I relax on the Outer Banks and revel in just doing nothing. Until then, I will have to be content with posting commentary on this exciting development and hoping that something more lively to discuss on this blog comes along in the meantime.
macintosh mac macbook

Data security: don't be blind to the big picture

I've been told that I should start this first post with a comment indicating that this is my first post. OK, that was fun - I'm glad that is over with.

I read an interesting editorial this morning on the issue of database encryption that got me thinking about the parable of the 6 Blind Men and the Elephant. In the editorial, the author discusses the possibility of using database-level encryption as a means of protecting sensitive data from a user who was not allowed to see it.

What got me thinking was the fact that the author, who has worked or is currently working as a DBA, takes an approach that I think overemphasizes the importance of database security features in addressing data security while not addressing other areas of greater risk. He can be forgiven for this view - from my experience, DBAs tend to be very smart but very narrow in focus. Of course a DBA would attempt to address problems from the perspective of the database - it's what DBAs know and work with every day and it's what they are most comfortable with. So in that way, DBAs are describing the "elephant" of data security using the knowledge that they have "in hand".

While I won't claim to be able to see the entire elephant, I do believe that there is much more to data security than simply configuring database security settings. Most people would agree that when managed well, relational database management systems offer an extremely secure environment for sensitive data. Through the use of features such as authentication, authorization, permissions (user-level and group-level) auditing, and more, it is very, very difficult to accomplish unauthorized access to database information. Unfortunately, there always comes as time when the information stored in the database must be processed or consumed by an application and that is when the risk to the data becomes greater.

In a typical configuration, a production database is running on its own server while the application accessing it is located across a network on a separate client or server platform. If database encryption is employed, the data that is sent to the application must first be decrypted before being sent to the application over the network. In an era where quality network packet sniffing tools are available to anyone with a a little know-how and an internet connection, there is always a possibility of someone capturing and logging the packet information. Despite this possibility, articles like the editorial mentioned above fail to emphasize the importance of securing critical data once it leaves the security of the database and passes over the network.

Most commercial database vendors now support some form of encryption of data over the network, typically through the use of SSL or some related data encryption protocol. In this scenario, before data is transmitted over the network via TCP/IP, it is encrypted. Once across the network and received, the packets are then decrypted and processed appropriately. If intercepted in transit by a packet sniffer, the data is gibberish and useless. When used in conjunction with database encryption, such network encryption makes the overall data environment much more secure and much less vulnerable to viewing by inappropriate audiences.

To be clear - there is more to data security than database encryption and network encryption. All of the security features employed within a production environment must work together and compliment each other - in contrast to the blind men in the parable who each believe his own narrow view of the elephant is correct. If you don't consider all of the pieces of the application stack that handle your sensitive data - application, data connectivity, database, network, servers, etc. you could end up with a security infrastructure that protects your elephant's tusks, but not it's tail.

Technorati Tags | |database encryption database+encryption data+encryption SSL data+security database+security SSL+encryption network+encryption